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
