Re: Beyond Inside-Out

[xdg]

I question whether this statement is really a correct characterization of inside-out objects:

# - No method of an inside-out class accesses (de-referrences) the body of its objects directly.

When using inside-out classes for 'black box' inheritance, this is often exactly what is desired, e.g. subclassing an IO::File or other unusual base object type.

Overall, it's an interesting approach and you've clearly given it a good deal of thought -- but I don't really understand how this is "beyond" inside-out objects -- rather it's an extra level of indirection and I'm not entirely clear what the benefits are or whether those offset the 'costs'.

On potential costs/downsides:

• Compile time field name checking is lost (as someone else mentioned)

• Overhead of calls to ego (vs refaddr) -- Inside-out classes that offer "black box" inheritance still require overhead of calls to refaddr. Both can be cached outside of loops, so this is really an issue of just ego vs refaddr (which may not matter for most applications). And Object::InsideOut's array implementation with the index stored in the object itself will be faster than either approach anyway (but doesn't do direct "black box" inheritance as a consequence).

• With "regular" inside-out classes, getting at the lexical storage of data from outside the file scope requires fiddling with PadWalker, whereas it looks as if ego could be fooled because of caller to access underlying data. (Maybe this is covered in the XS discussion which I didn't really follow completely.) If so, "breaking" encapsulation becomes easier from the outside. (Some might consider that a feature, I suppose.)

I'd be interested in a concise summary of the features/benefits. Right now I really only see one:

• Classes get "inside-out" property storage without needing to define fields and associated data storage hashes/arrays explicitly.

(Though I personally question whether that is really a net savings in characters typed if accessors will need to be defined for most fields anyway or if some sort of field-name validation is added.)

[Anno]

I'd be interested in a concise summary of the features/benefits. Right now I really only see one:
• Classes get "inside-out" property storage without needing to define fields and associated data storage hashes/arrays explicitly.

  I see three major points going for the Alter proposition. Rewording the one you mention,

• In an Alter-class you get to keep Perl's original model, "an object is just a reference...", only each class gets to see its own reference. The ingenious twist of using a hash "inside-out", keyed by the object('s id) is not needed. If you want your object to "be" a hash keyed by field name, that's fine. If it's naturally a scalar, or code, you can have that too.

• Second, Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.

• Third, though this hasn't been conclusively demonstraded in code, it is possible to provide generic hooks for Data::Dumper, Storable and the like that support all Alter classes and which can be inherited or even imported. With inside-out classes, this is hard to achieve because only the class knows where its data is stored. An Alter-object carries all its data with it, ready to dump and able to be restored.

  As for the cost, you have rightly observed that both techniques require the call to either id() or ego() on each access, with equal possibility of caching. The call to id() is essentially free, except for the call overhead, but ego() has a hash access in the path, which counts. Preliminary benchmarks show that the impact is measurable, but not dramatic. At the moment I am less concerned with efficiency but with getting it right.

  On a broader note, inside-out has shown what it takes to make black-box inheritance work in Perl. In particular, some kind of out-of-band storage is needed for which it cleverly uses the existing refaddr() as a primitive. My goal is to design a primitive (ego()) for out-of-band storage expressly for the purpose. In that sense I consider the sketch of the Alter module we're discussing a step beyond inside-out.

  This discussion (and another one on clpm) is helping me to spot potential problems and limitations of the approach.

  Anno

[xdg]

Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.

An Alter-object carries all its data with it, ready to dump and able to be restored

I think these are only true if the object reference is a hash/array that stores the references for each class. If so, you give up encapsulation and the ability to do "black box" (aka "foreign") inheritance.

If Alter uses inside-out techniques behind the scenes and the object reference is a key into data storage maintained by Alter with the references for each object for each class, then you still have all the garbage collection and threading problems inherent to inside-out objects.

Even if you use Hash::Util::Fieldhash, that just pushes the issues into the Perl core and it's not backwards compatible before 5.9.4 (at least, I think not).

[Anno]

Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.

An Alter-object carries all its data with it, ready to dump and able to be restored

I think these are only true if the object reference is a hash/array that stores the references for each class. If so, you give up encapsulation and the ability to do "black box" (aka "foreign") inheritance.

No, that's not so. An Alter object stores its data in a hash that is magically (in the technical sense) attatched to the object (which can be of any type). Magic is unique in that it is inaccessible to normal Perl (except through the interface you want to provide), but is serviced in garbage collection and thread cloning.

Anno