Re^4: Beyond Inside-Out

...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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]