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.

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

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.

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.

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

One of the major design goals of Moose is to "play well with others". So far at $work have successfully integrated it with CGI::Application, or course we can't utilize all that Moose has to offer (attribute handling and instance construction to name a few), but we have found lots of use for Moose's method modifiers. The work with DBIx::Class and Catalyst is all fairly new, but so far has seems to be going smoothly.

Can Moose be (safely) subclassed without extends?

Let me first clarify that in order to use Moose you do not subclass it. Much like you module Class::InsideOut it exports functions into the class's namespace to provide it's features. In fact Class::InsideOut actually inspired me to use this approach in Moose. Now, onto the questions:

All extends does is to set the @ISA, the reason it uses extends and not base is to make sure that all Moose classes inherit from Moose::Object unless otherwise specified (through extends). I won't bore you with the details, but just know that extends is pretty much just optional sugar.

Can Moose subclass a non-Moose class?

This, as you very well know, is tricky given the many possible different instance structures Perl 5 OO offers. The short answer is yes, Moose can do this (and we do it with our Moose-ified CGI::Application). However, things get tricky when you need to deal with the details of instance construction. Currently both Moose and Class::MOP only support blessed hashes, but this is because that is what I use, and not a restriction of these modules so much (although changing Moose over at this early stage would be pretty sticky). Now, onto the "how" of this question:

The (fairly common) idiom of calling $class->SUPER::new and then reblessing is reworked in Moose to look like this:

my $super_instance = $class->SUPER::new(@_);
my $self = $class->meta->new_object(__INSTANCE__ => $super_instance, @
+_);
[download]

Ugly I know, but it does the trick if you are just dealing with blessed hashes. It is no better or worse than the non-Moose version IMO. From this point on in your class hierarchy you can use Moose normally, in other words, it doesn't ripple upwards.

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

Well, if we need to add state, then Moose can't do that. This is because File::Marker is an inside-out object which wraps a blessed GLOB reference (an IO::File instance), and thats just too many different modes of instance storage to deal with.

However, if you only need to add or augment behavior, and not state. Moose and it's method modifiers (before, after & around) could prove quite useful.

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.

That is actually exactly the goal of Moose, to not require a fundamental change in the way you do Perl 5 OO, but instead to try and expand on the existing model.

-stvn