Re: changing the default base class

Jonathan,

On Nov 17, 2006, at 9:20 PM, Jonathan Swartz wrote:
>> I agree it is uglier, however, I don't see it as a violation of DRY.
>>
>> Most class hierarchies are not so shallow that you will have to  
>> say extends 'My::Moose::Object'; more than a handful of times. In  
>> my experience, having to do this helps to delineate the "base" of  
>> your hierarchies, where as use My::Moose would be spread all over  
>> your class hierarchy. This to me is a violation of DRY.
>>
>
> Sure, the number of classes that inherit directly from the base  
> class might make up a minority. But by that same logic, why  
> wouldn't you require people to inherit explicitly from  
> Moose::Object? :)

Actually Moose::Object is needed for Moose classes to function in the  
expected way (providing a constructor, the does() method for checking  
roles, and the means to run all BUILD and DEMOLISH methods). But I  
actually don't require you to inherit from Moose::Object, I just make  
it the default. If you want to inherit from another class, I don't  
prevent it, nor do I try and force Moose::Object to be part of the  
hierarchy.

> It isn't so much the tedium of adding the 'extends' statement as  
> the consequence of someone *forgetting* to add it for some random  
> class. In that case, we'll have the wrong base class in one part of  
> the hierarchy, leading to obscure bugs.

True, your approach will solve this. But to play devils advocate,  
something like this should get picked up in code reviews.

> More generally, this isn't just about default base class - that was  
> just the initial motivating factor. I want to prepare for the  
> possibility that I'll want to tweak some other Moose behavior or  
> policy (in a perfectly external, API-respecting way) for the entire  
> project, after hundreds of classes have been created, and I don't  
> want to have to insert a new policy statement in all those classes.

I see the reasoning here as well, however (and this is just my  
personal opinion, and development approach), this also ties you down  
to /your/ Moose version. This is where I think a Log::Log4Perl style  
config file would be more powerful since it would allow you to vary  
metaclasses much more easily from a central location, and do it based  
on package namespaces. I might try and sketch out this idea more this  
weekend.

> Though I suppose one could argue that most languages with strong OO  
> support never give you this much ability to control meta-OO  
> behavior, and people seem to do okay. And that allowing mass- 
> customization of Moose will tend to make classes less portable.

Well, Smalltalk and CLOS give you similar degrees of flexibility, but  
in practice it is not used that much. Ruby gives you a lesser amount  
of flexibility in it's meta-ness, and people seem to be really  
experimenting with it a lot lately to do DSL-ish things. At some  
point though, messing too deeply with the meta-layer is dangerous,  
and ill-advised. Hell, I wrote the thing, and I try to keep my meta- 
level-fiddling to a minimum :)

As for the mass-customization leading to less portability, you are  
correct, LISP kinda suffered from this in the early 80s, and that is  
why CLOS was standardized. However, because you can specialize  
metaclasses (and sub-metaclasses like attributes, methods, etc) on  
such a granular level (per-package, per-attribute, and even per- 
method if you want), it is only an issue when you start subclasses  
between heavily customized meta-schemes that you run the risk of  
problems. This is basically the "metaclass incompatibility problem",  
which is pretty well known (I link to some papers in some of the  
POD), but with no agreed upon definitive solution. Moose takes a  
"blow up if it gets too hairy" approach, although, you can override  
this too, so if you *really* want the trouble, its all yours :)

- Stevan