Re: changing the default base class

On Nov 17, 2006, at 9:00 PM, Jonathan Swartz wrote:
>> My concern with allowing Moose to be overridden is that it either it;
>>
>> locks me into the internals of Moose.pm (not only can I not change  
>> it, I cant improve it or extend it)
>>
>> OR
>>
>> causes simple updates to break your *entire* system in one fell  
>> swoop :P
>>
>> I don't like either option actually. To be honest, 99% of all the  
>> problems people will try to solve by wrapping Moose can be solved  
>> by some other means (custom metaclasses, using roles instead of  
>> classes, etc).
>
> I can see why you would not want to make Moose overly subclassable.  
> Especially at this early stage, you need to have the freedom to  
> muck with internals and keep the supported API small.
>
> But I don't see how Eric's suggestion opens things up any more than  
> standard Moose::Policy usage does. Isn't his syntax functionally  
> equivalent to including a 'use Moose::Policy' in every class in a  
> project, just more sugary? Or are you saying that you would like to  
> discourage overuse of Moose::Policy itself?

Well, it all depends on how pass_through would work. I would be fine  
with that or the use Moose policy => ... being sugar for  
Moose::Policy usage, and/or some kind of Moose::Policy global config  
ala Log::Log4Perl.

I would rather encourage Moose::Policy usage than Moose subclassing  
to be honest, since really there isn't that much in Moose to actually  
subclass. All the guts of it are in Moose::Meta::* classes, which is  
what Moose::Policy is designed to work with.

- Steve