I am not amazed that it is just this feature that is problematic in Object::InsideOut. Inheritance from a non-inside-out class is exactly where a full inside-out class exploits its agnosticism with respect to its body. Any actual object can be substituted and still allow access to the data that are implemented inside-out style. Once you use the body, for anything at all, this feature goes away. In the case of Object::InsideOut, the body must contain the id as a scalar, or behave as if it did. I don't know how Object::InsideOut solves the problem, but it can't be straightforward.
The inside-out technique brings two things that are lacking in traditional Perl OOP: encapsulation and (almost) unimpeded inheritance. Of the two, the implicatrions on inheritance are far more important. Not because of any theoretical reasons, but because the lack of encapsulation hasn't had any serious consequences. People don't access the innards of an object directly, and that is that.
The lack of free inheritance has hindered the development of OOP in Perl. You want to subclass an existing class from CPAN? Well, you can't without getting intimately involved in the implementation of the prospective superclass. If your class is inside-out, or if the superclass is, the problem goes away. That makes a big difference.
There is deplorably little code reuse among the classes on the CPAN. When inside-out becomes more common, that could change.
Anno
In reply to Re^3: Difficulty with Object::InsideOut
by Anno
in thread Difficulty with Object::InsideOut
by herveus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |