The thing about Moose is that it isn't really addressing the issue that the OP cited -- that the "default" approach to objects in Perl 5 is blessing a hash and storing attributes in the hash -- as it doesn't address the encapsulation and substitutability issues (what has come to called "foreign inheritance" by inside-out authors).

Moose is built with Class::MOP, which provides some nice sugar, but doesn't really change the underlying behavior. From the description of Class::MOP:

This module is an attempt to create a meta object protocol for the Perl 5 object system. It makes no attempt to change the behavior or characteristics of the Perl 5 object system, only to create a protocol for its manipulation and introspection.

What it does well is to allow for various types of introspection. (See stvn's response to my question about this in another thread.) This is very helpful for object-relational mapping like DBIx::Class and (I'd imagine) request-dispatch mapping frameworks like Catalyst. The fact that Moose is proving useful to these applications doesn't mean that it's well suited for all types of problems. (It doesn't mean that it isn't, either.)

And while it might be possible to build inside-out objects using Class::MOP, the InsideOutClass example bundled with it has substantial missing pieces and is currently YABIOOI (yet another broken inside-out object implementation). When I have enough tuits, I might tackle a proper inside-out implementation using Class::MOP.

I have great respect for stvn, and I'm glad to see some of the insights from the Perl 6 object system migrating back to Perl 5, but I don't think that Class::MOP or Moose really address the underlying issues that the OP was asking about -- though they do bring some useful systematization to Perl OO techniques and make it easier to address the problems that exist today.

For that matter, it should be noted that inside-out objects aren't a panacea, either. They solve a couple of problems, but at the cost of a substantial increase in complexity.

It's all the more reason to look forward to Perl 6.

You are absolutely correct that Moose and Class::MOP both do not attempt to change the underlying fundementals of Perl 5 00, it attempts to augment them in such a way that all the (sometimes dangerous) flexibility is retained and all the tedious repitition is removed. To address the quote the OP gave:

This is quick and easy, but it has encapsulation, substitutability, and namespace clashing problems.

The need for strong encapsulation is (IMO) overblown. In many of the application domains where perl thrives, it is not really needed, and if you do find you really need it, you probably shouldn't be coding in Perl anyway. Of course encapsulation has a social component to it as well, a "keep out the dumb programmer next to me" feature. But honestly, I think that issue is better addressed by social policy than by language features.

As for substitutability, a well designed class will not have this problem. In fact I can break substitutability in just about any language, although languages with strict type systems are harder than dynamic languages like Perl/Python/Ruby/etc. A well designed class hierarchy will not break substitutability, a language compiler/runtime which double checks that for you is nice at times and restrictive at others.

The "namespace clashing" is a little ambiguous, it sounds to me like a C++ism and really just another word for encapsulation. In that case, my above comment applies.

So all that said, you can see why i did not try to address these items with Moose and Class::MOP, I don't see them as dire problems. The dire problems I see with Perl 5 OO is the tediousness manual nature of it. Too often I find myself writing the same code over and over. Things like constructors, slot creation and initialization, accessor methods, the list goes on and on. Solutions like Class::Accessor, Class::MethodMaker, etc. only address certain issues and either don't handle the others, or worse, handle them poorly. I do not think this is a failing of these modules (or their authors), but a failing of Perl's OO facilities in general. In short, it's extreme flexibility makes enforcing consistency difficult, and without some consistency these problems cannot be solved. The primary goal of Class::MOP is to create a meta-level infrastructure which can serve as that layer of consistency, while trying to not enforce that consistency on the user (non-meta) level.

Now, some people might not see that tedium I mention as being nearly as important as things like encapsulation. I disagree, reducing tedious and repetitive coding means reduced errors. And not logic errors, but stupid errors, silly ones that you can spend hours trying to hunt down cause you wouldn't think to look in that tedious repetitive code you have written 1000 times. And all that tedium usually means duplication, which is where simple typing errors and misspellings can easily creep in. If you only ever write the name of your attribute once (in it's attribute definition) and the meta-level handles things like slot initialization, accessor generation, etc., simple spelling errors then become much less common.

But enough babbling, let me address some of your comments:

And while it might be possible to build inside-out objects using Class::MOP, the InsideOutClass example bundled with it has substantial missing pieces and is currently YABIOOI (yet another broken inside-out object implementation). When I have enough tuits, I might tackle a proper inside-out implementation using Class::MOP.

I am sure It is quite broken, but it is mearly a proof of concept for alternate instance storage schemes, and not meant ever to be used seriously. The missing piece are left as an exercise to the reader *cough* hint hint *cough* ;)

I'm glad to see some of the insights from the Perl 6 object system migrating back to Perl 5, but I don't think that Class::MOP or Moose really address the underlying issues that the OP was asking about -- though they do bring some useful systematization to Perl OO techniques and make it easier to address the problems that exist today.

Actually, my point above is that a "useful systematization to Perl OO techniques" actually can go a long way to solve the underlying issues the OP is talking about. Of course YMMV and TIMTOWTDI.

For that matter, it should be noted that inside-out objects aren't a panacea, either. They solve a couple of problems, but at the cost of a substantial increase in complexity.

I actually think that a meta-level infrastructure like Class::MOP might be just what inside-out objects need to help reduce that complexity. By moving the complexity up the meta-chain, you move it out of the view of the casual user, and still keep it accessible to those who need it.
-stvn

The need for strong encapsulation is (IMO) overblown.

I'm pretty sure I wrote the article to which the OP refers (What is Perl 6) and what I meant is that unencapsulated access to attributes in a parent class outside of pure accessors dictates the implementation of descendent classes.

Try subclassing IO::Handle sometime.

I don't particularly care if it's possible for someone clever or committed or crazy to do bad things with the internals of my objects with reflection or XS or ugly hacks. I do care if I have to work around someone else's poor implementation choices because of bad defaults.

Stronger encapsulation keeps the details of the implementation of a class behind an interface, where it belongs.

The need for strong encapsulation is (IMO) overblown. In many of the application domains where perl thrives, it is not really needed, and if you do find you really need it, you probably shouldn't be coding in Perl anyway. Of course encapsulation has a social component to it as well, a "keep out the dumb programmer next to me" feature. But honestly, I think that issue is better addressed by social policy than by language features.

The point I make in my Inside-Out tutorial presentation is that people frequently mistake encapsulation for hiding information. I see encapsulation as insulating users and subclassers of a class from its implementation. Social policy can work within a team, but it doesn't help when Module::X on CPAN that you subclass suddenly switches from hash-based to array-based (or inside-out) implementation.

As for substitutability, a well designed class will not have this problem. In fact I can break substitutability in just about any language, although languages with strict type systems are harder than dynamic languages like Perl/Python/Ruby/etc.

I see this as more related to the first point. Consider all the mess that UNIVERSAL::can/isa play with things like Class::Adapter -- substitutability needs to be at the interface level, not the blessed or reftype level.

The "namespace clashing" is a little ambiguous, it sounds to me like a C++ism and really just another word for encapsulation.

Yes and no. Within Perl and in reference to hash-based objects, I think this refers to how keys within a blessed hash can clash between super/subclasses. That is an encapsulation issue, but the way it crops up even without changing the type of the blessed reference is very specific to the history of how objects are created in Perl.

I actually think that a meta-level infrastructure like Class::MOP might be just what inside-out objects need to help reduce that complexity. By moving the complexity up the meta-chain, you move it out of the view of the casual user, and still keep it accessible to those who need it.

I need to understand Class::MOP and how it's used for Moose much better, but from what I saw in trying to understand Moose's capabilities, I have a sneaking suspicion that it might be possible to wrap Class::MOP around Class::InsideOut without too great a struggle. (Things like serialization might become interesting.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Actually, it does provide for everything the OP asked for. You just have to drink a little more Koolaid. Class::MOP doesn't provide much outside of sugar. But, Moose does. Using 'extends', you can safely subclass. It doesn't guarantee much (yet) in the way subclassing non-Moose stuff, but we're only on 0.03_02 - lots more to go. :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Using 'extends', you can safely subclass. It doesn't guarantee much (yet) in the way subclassing non-Moose stuff, but

But that is, unfortunately, exactly the issue. Almost every class framework in Perl works fine as long as you consistently use that framework.

Can Moose be (safely) subclassed without extends? Can Moose subclass a non-Moose class? If so, I applaud highly. But, as you say, it's still 0.03_02... there's a long way to go until the OP's questions are fully addressed.

If you can show me how Moose could be used to subclass, say, File::Marker, then I'll be a believer, but short of that, I think it's a nice wrapper around all the old problems.

It's a very nice wrapper and will work for most people for most things, I'd bet, but it's not a fundamental change in the way that I think inside-out objects are. (And as I said, those should be used with caution too.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

I thought Moose was an experiment from the Perl 6 people. Gah.

It started out that way. But, after sri (Catalyst) and mst (DBIx::Class) started playing with it, they liked it and wanted stvn to productionize it. :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?