On Mon, 21 Dec 2009, Stevan Little wrote:
Okay, I am not sure these should be subclasses of Class::MOP::Object, it
implies that they could perhaps be instantiated, which I don't think they
ever should be. If we are not going to put a role mechanism into Class::MOP
right now and going to use MI instead I think we should embrace the idea of a
mixin and just enforce careful usage of it. This means changing the names to
Class::MOP::Mixins::HasMethods and Class::MOP::Mixins::HasAttributes and
removing the inheritance from Class::MOP::Object. The result is that we are
writing them more like roles (collections of methods which can never be
instantiated) but composing them via multiple inheritance. Honestly, this is
not ideal and I would shun this idea in $work code, but that is because we
have a better alternative, which is roles. But given this is a code base
which should only be fiddled with by people who know it really well, we can
count on proper disciplined usage of mixins/MI and therefore should use the
concept fully.
That all makes sense to me. I'll make those changes in the branch.
When an attribute is added to a role, it gets an additional trait added to
it, Moose::Meta::Attribute::Trait::InRole. An attribute in a role does not
generate any methods (yet?).
This ::InRole trait also wraps the clone method to _remove_ itself as a
trait when the attribute is cloned. In other words, cloning an attribute
with the ::InRole trait returns a new attribute without that trait.
As you might guess, when a role is applied to a _class_, the role's
attributes are cloned and added to the class. The class ultimately ends up
with a copy of the attribute minus the ::InRole trait.
I am not sure this is the right way to go about this, it seems wrong to me.
Why not have a Moose::Meta::Attribute::Role class which is a representation
of an attribute in a role? It would likely be simpler then
Moose::Meta::Attribute so perhaps adding a Moose::Meta::Attribute::Basic or
something which they could both share as a base class would work.
The Moose::Meta::Attribute::Trait::InRole really feels a lot like it is
monkey-patching Moose::Meta::Attribute to me.
The in-role-ness needs to be a trait so that attributes added to roles can
have a metaclass option set (along with traits and such).
I suppose it could be redone with a shared parent, where the in-role
attributes simply save the metaclass and traits option, and these don't
actually get applied until the attribute is added to a class. This seems
rather more complicated, though.
And really, the parent class should be part of CMOP, because ideally a
role attribute wouldn't have methods like ->get_value and such, since they
don't have values. I wouldn't mind doing this, mind you.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
