They both see basically the same thing wrong with Perl's object system as it is normally used and try to fix it in different ways

With Inside-Out Objects, everything starts to look like a hash. With Closure Objects, everything starts to look like a subroutine. A subroutine call is ultimately more flexible than a hash lookup (unless you want to open the can-of-worms that is a tied interface). However, you have to put more work into it.

IMHO, Inside-Out Objects rely on subtle behavior on Perl's part that make some people feel uneasy. Further, the technique isn't necessarily easy to grasp, even to those that have already mastered Perl's regular object system.

They may also appeal more to those with a functional programming background.

Anyway, for a totally different way of doing OO using closures (no 'bless', but with inheritance, AUTOLOADING and SUPER), look at one of my earlier attempts to bypass Perl's OO problems:

I guess one could say it solves the data inheritance problem - but in an extremely awkward way: the superclass defines the attributes of the subclasses. At least, that's how inheritance is happening in your example.

Yes, this is something I need to think about more. I think it's possible, but the specifics haven't been worked out. (Along with a lot of other ideas).

Much of the power of Closure Objects will depend on how much work you're willing to put into the closure.

First, your closure method eventually stores the attributes in a hash. You are just using the closure to give each object its private lexical hash.

That is how it is currently implemented, but there's no reason why it has to be limited to some access controls and a hash lookup. The technique enforces the "eat your own dogfood" rule (i.e., if you define accessors/mutators on class data, use them even inside the class itself). It allows for a lot of things that would otherwise have to be done by a tied interface.

Frankly, I fail to see how they connect to 'functional programming'.

Closures come straight out of functional programming. Plus I like ideas that combine concepts that are normally thought of as completely seperate.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

That is how it is currently implemented, but there's no reason why it has to be limited to some access controls and a hash lookup.

Oh, sure, but that's isn't anymore true for your closure solution as it is for more traditional methods (IO::* for instance uses blessed handles), or for Inside Out objects.

Abigail

1. The fact that I like closures, does not argue that I should want to always use closures. The key difference between OO and using closures heavily is in how you organize code, not how you implement things. Once I've chosen to organize things in an OO fashion, then I'm going to find my code growing in ways that OO code does, and OO design principles will be applicable.
2. One of the big OO principles is the open-closed principle. Modules should be open for extension and closed for modification. That is, you should be able to leave a base class alone and usefully extend it by subclassing. This ideal is more often honoured in the breach than the observation, but it is worthwhile trying to think in terms of designs that can work that way.
3. The open-closed principle says that the closure approach is worse than alternatives. You can't make unanticipated changes without either changing the base class implementation, or else working around the implementation with something like inside-out objects.
4. Personally I value having Storable work more than I do ways of enforcing encapsulation. Therefore I don't have problems with the traditional hash approach.