Re^2: Difficulty with Object::InsideOut

Howdy!

Object::InsideOut uses lexical arrays to store attribute values, so it needs to store the array index somewhere. The "inside-outness" comes from the fact that even if you know the index, you can't get to the arrays to break encapsulation. That doesn't violate "inside-outness".

I was trying to use the ability to have a class inherit from a foreign (non-Object::InsideOut) package. In this case, I'm wrapping a Set::Scalar::Valued object, and I want a Morsulus::Catalog::SetOf object to be able to inherit the methods from Set::Scalar::Valued. According to the docs for Object::InsideOut, I simply call the inherit method and pass it an instance of the foreign object. In my example, I'm also going so far as to keep that object as an attribute of my SetOf object.

I elected to try Object::InsideOut because it offers a richer set of features than Class::InsideOut, and it's not doing things that Class::Std does that have bad implications (CHECK blocks come to mind as potentially problematic).

Oh, and I looked at the test suite for Object::InsideOut to see how it tests the foreign inheritance functionality. I don't see the difference, and I can't discern just what additional arguments inherit is expecting.

yours,
Michael

Comment on Re^2: Difficulty with Object::InsideOut

Replies are listed 'Best First'.
Re^3: Difficulty with Object::InsideOut by Anno (Deacon) on Mar 25, 2007 at 01:52 UTC
I was trying to use the ability to have a class inherit from a foreign (non-Object::InsideOut) package. 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	[reply]
Re^4: Difficulty with Object::InsideOut by herveus (Prior) on Mar 25, 2007 at 16:20 UTC
Howdy! Actually, I think that Object::InsideOut does manage it, but there is something going on in Set::Scalar that makes the behavior really weird. Set::Scalar does a lot of overloading, and that may be part of the problem. I'm not sure that the problem lies within Object::InsideOut. Object::InsideOut tries to provide a clean way to drag a "foreign" class into the inheritance tree so that you can freely inherit from non-Object::InsideOut classes. I think I managed to run into a pathological case. Inside-out objects can, as a general case, be any sort of blessed reference. The key characteristic is that the attributes of the object are not stored in that reference. The ID of the object is not one of the visible attributes, and I think the innards of Object::InsideOut make the referent read-only as well. Class::InsideOut includes a discussion of what was available on CPAN to support inside-out objects, including brief critical assessments of each, noting strengths and weaknesses. Object::InsideOut fared well, and I don't see this little exercise in digging into packages and experimenting with -MO=concise as contradicting the essence of that. yours, Michael	[reply]
Re^5: Difficulty with Object::InsideOut by Anno (Deacon) on Mar 25, 2007 at 20:52 UTC
Well, I don't want to dissuade you from using Object::InsideOut. It brings a wealth of features whose utility may require a second glance to appreciate. I maintain that an inside-out object that touches its body (visibly or not) is in a state of sin. Its class must labor hard for the accomodation of foreign classes, unlike those whose objects are without that sin. Anno, who wonders how he gets to express so puritan views Update: Minor change in wording	[reply]