Re: Moosifying Test-Run Part 2: Probably Not

Shlomi,

On Jun 2, 2008, at 3:24 AM, Shlomi Fish wrote:
>>> The problem as I see it is that I'm using Plug-ins instead of Roles
>>> and that I didn't finalise the class. Of course, I'd rather not
>>> finalise the class, or ditch away plug-ins.
>>
>> I think perhaps you misunderstand the use of the "immutable"  
>> feature. First,
>> it is not finalizing, in the C# sense of the word, where it prohibits
>> subclassing and such. Making a class immutable means that the  
>> metaclass can
>> longer be altered, it allows Moose to then create an inlined  
>> constructor as
>> well as memoize several of the more commonly needed bits of data  
>> in the
>> metaclass. This is much less restrictive then you might think, and  
>> unless
>> you are doing lots of ->meta hacking, you will never need to care.
>
> Actually, I only use "finalised" because I could not remember the
> "immutable" term, and was too lazy to look it up. But I meant
> immutability. I know that what immutability does is as you described,
> but I don't want that, because I may still want to have further
> plugins added to the class.

Yes, but as I describe below, you can make your class immutable, get  
the benefits, and if you use roles, still be able to add plugins. The  
only reason for not using immutable is if you actually want to (using  
the MOP) alter the class at runtime (add_attribute, add_method,  
changing @ISA with superclasses, etc.).

>> I am not sure how you are doing plugins, but there are two ways to  
>> go about
>> this in the Moose world utilizing roles.
>>
>> 1) Compile-time
>>
>> This is plugins that you can know about during class construction  
>> time, and
>> are *class* specific. So you simply create your class, applying  
>> the roles
>> for the plugins. Often times, this is enough and runtime pluggable- 
>> ness is
>> really overkill and not actually necessary. The key thing about  
>> this is that
>> it is *class* specific, meaning you will want several instances of a
>> specific class (with a specific set of plugins applied to it) in your
>> application.  This may require creating a few extra subclasses,  
>> but really
>> if your application doesn't require arbitrary combinations of plugins
>> applied to arbitrary instances of varying classes, then this may  
>> actually
>> help increase the clarity of you design.
>>
>> Now, since this is all compile-time defined, obviously it does not  
>> hamper
>> making a class immutable.
>
> I actually may need to add plugins at run-time.

Well then a combination may be the best, create as many combinations  
up front as possible. These two options (compile-time roles & run- 
time roles) are in no way mutually exclusive, you can easily do both.

>>> And naturally, Moose is
>>> also making many run-time checks that are not present in my old
>>> Class-Accessor and are not really necessary for me. As much as I
>>> appreciate type-checking for instance members, I'm disciplined  
>>> enough
>>> for it not to matter much.
>>
>> So just remove the types, it is that simple since they are entirely
>> optional. In fact, the accessor generated by Moose for this:
>>
>>  has foo => (is => 'rw');
>>
>> if *faster* the the typical Class::Accessor version since it never  
>> creates a
>> lexical $self, and just uses $_[0] instead. Moose does as much as  
>> it can to
>> only make you pay for the features you use, but it cannot remove  
>> the cost of
>> features you use, but just don't really want ;)
>
> Yes, but to me it seems that it beats the point of using Moose. If I'm
> using Moose, I'd rather have type-checking, so people will know what
> every class member is.

Well, you want it, but don't want to pay for it?

Nothing in life is free my friend :)

> Back to the topic: I still feel that Moose is a bit unsuitable for the
> style of OO I used in Test-Run.

This is fair, if you don't want to use it you don't have too.  
However, I still think perhaps you have not explored it deeply enough.

Moose is what is called a "disruptive technology" for the OO Perl  
world. Even though it is not as performant as the existing solutions,  
it provides enough new features and such that people are finding it  
compelling enough to use it anyway. As we continue to improve Moose  
it will only get faster and move out from the "disruptive" realm, but  
this (of course) takes some time.

It is also important to see Moose not as a "drop in" replacement for  
old style Perl OOP, but as a new way of approaching Perl OOP. So  
while Moose does work well with existing classes written in old style  
Perl OOP, it does not work well with some of the bad habits and ad- 
hoc techniques that have developed over the years with TIMTOWTDI- 
inspired OOP. As I have been telling the CataMoose people (the guys  
porting Catalyst to Moose), they will get more gains by re-writing  
then by simple naive porting.

- Stevan