Re^3: Beyond Inside-Out

Thus the mechanism is: Equip each object (magically) with one hidden hash, its corona. Use that hash, keying by class name, to store the individual alter ego of the object for each class.

This reminds me of another "make inheritance work" technique I'd heard of. Every object is a hash ref (as usual), but every class has their own key into it. Basically every object looks like the $corona in clinton's description. The Alter advantage over that method is mainly privacy. The various classes sharing space can't meddle with each other's attributes. If ego is changed to address tye's concern (so that a class can specify its own name), I'm guessing that Alter loses that advantage too. At that point, you might as well write a base class with ego in it.

Comment on Re^3: Beyond Inside-Out Select or Download Code

Replies are listed 'Best First'.
Re^4: Beyond Inside-Out by Anno (Deacon) on May 31, 2007 at 14:32 UTC
...reminds me of another "make inheritance work" technique I'd heard of. Every object is a hash ref (as usual), but every class has their own key into it. Basically every object looks like the `$corona` in clinton's description. The Alter advantage over that method is mainly privacy. No, the point isn't privacy, it's being out of band. The corona is attached as a piece of magic to the object which remains free to be anything. That keeps the actual object body uncommitted, a requirement for black-box inheritance. Privacy is only secondary, its lack has never been a big deal in Perl OOP (or other Perl, for that matter). The problem isn't that one class can access another's data, the problem is that there is nothing else for it to access. Inside-out and `Alter` are different ways of addressing that problem. Anno	[reply] [d/l] [select]
Re^5: Beyond Inside-Out by kyle (Abbot) on May 31, 2007 at 15:43 UTC
I may think out loud here a little. With `Alter`'s magic corona, you can integrate with an existing anything-based object and be anything you want. It doesn't matter what the other object is, you can get along with it, and it can get along with you. This is true also of an inside-out object that uses the reference as a key into its attribute hashes. The problem is that the inside-out object has some overhead in the form of a `DESTROY` method, and it has to go out of its way to deal with threading. They both have to do something special to support Storable (I wonder if my overload trick would help with that, but probably not). They both have some overhead for practically all self-access (`ego` vs. `ident`/`refaddr`/etc.). If the magic corona's key is based only on caller, there's a problem with methods called via some avenue other than the package they were compiled in, but that's not such a big deal if you can tell `ego` what key to use instead. So I'm thinking that interoperability-wise, they're about the same. That said, there may be implementation details to worry about, but my head is already swimming a little. The technique I wrote about before is another way for classes to work together in an object regardless of what they want to be, but they all have to be aware of it. For that reason, it's not interoperable. OK, I think I have a little more clarity now. Thanks for reading.	[reply] [d/l] [select]


Do you know where your variables are?
	PerlMonks