Re: changing the default base class

Jonathan,

On Nov 17, 2006, at 10:01 PM, Jonathan Swartz wrote:
>> 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.
>
> Another example of this: If my application is using log4perl and I  
> have access to a well-known logger object, I'd like the option of  
> logging object creates and destroys and perhaps other general OO  
> activities. Unless Moose itself takes responsibility for this  
> (meaning a dependency from Moose to log4perl - unlikely), my custom  
> Moose subclass would have to.

This is the perfect example of what the AOP folks call a "cross- 
cutting" concern, and one which is solved really nicely with roles  
(aka traits, aka mixins). But this is perl after all, so as always  
"there is more than one way to do it" :)

But aside from roles, this is a problem better solved with a  
different base class, then with a metaclass.

- Steve