On May 20, 2008, at 8:53 PM, Ricardo SIGNES wrote:
* Stevan Little <[EMAIL PROTECTED]> [2008-05-20T09:47:17]
On May 19, 2008, at 8:30 PM, Bernardo Rechea wrote:
Grr, It would be quite a learning curve before I would able to
understand
Moose well enough to even try... Do you think at least that
having class
attributes declared in roles is reasonable?
No, I don't think it is reasonable.
Class attributes are really attributes of the metaclass instance
(Dave
implements them slightly differently then that, but the effect is the
same). When a role is composed into a class, Moose will merge all the
attributes and methods defined in the role into the class. It does
not
however merge all the attributes and methods from the metarole
into the
metaclass.
This sounds, to me, like an argument from implementation, instead
of from first
principles.
Is this statement true, outside the realm of how things are
implemented:
A role, when applied to a class, affects the behavior of
instances, and only
of instances?
I don't think it is, because it may add class methods.
Well the argument *could* be made that class methods and class
attributes are different, but then you can start getting into the
"objects are the poor mans closures" stuff and this isn't
comp.lang.lisp and I really don't want to go there anyway (so instead
I just point to it as I drive by :P).
Anyway, yes, it is somewhat implementation dependent (although it is
not entirely true, cause there is no reason Dave can't add this
feature, although it would be kinda tricky), but it also theoretical
too.
A truely *pure* object system would not have classes at all, a class
would itself be just an *instance* of $Class which itself would be an
instance of $Class (http://www.iinteractive.com/moose/images/
class_mop_model.jpg). In that sense, you don't ever distinguish the
difference between class and instance data, it is just obvious that
"class" data is means instance data in the metaclass.
I try to mimic this in Class::MOP as best I can, but in order to make
it useable and not full of AUTOLOAD crack, it has to bind itself to
the Perl notion of packages, classes and blessed instances. Once I
have the ability to overload -> (*wink*) then I can abandon the
(broken) packages == classes idea and be able to implement that more
pure system I speak about above (*cough* Moose 2.0 *cough*).
Now, I know that this may be a bit of a lame argument, since Perl
is so lousy
about distinguishing class and instance methods, so I will not
insert a
dramatic sting and an "AHA!" here. I just think that it's one bit
of evidence
that roles affect class behavior as well as instance behavior.
If that's the case, class attributes should be able to be provided
by a role.
Hmm, not sure that the argument for adding a feature should be "so
that it can match the other broken features" :P
If they can't be, then I could imagine myself very soon wanting to
start using
a lot more factory objects, which would be annoying.
My personal feeling is that class level data and methods are bad, and
that they should generally be avoided in a design. Quite often a
Singleton or even just a regular old instance will be enough to
replace that need. Of course, this is *my* approach and TIMTOWTDI so
feel free to ignore.
As for the "can this be done", yes it can, but currently we do not
have an easy way to hook into role composition to add features like
this into roles. This feature is on the TODO list (nothingmuch wanted
it recently for something), so we could use this as the impetus to
get this started (although tuits are somewhat in short supply for
nothingmuch and I because of $work).
- Stevan
