Okay, my comments are below:
On Dec 20, 2009, at 2:40 PM, Dave Rolsky wrote:
There are two branches for this, one for CMOP and one for Moose.
The CMOP branch is called topic/mi-methods-attributes. The "mi"
refers to multiple inheritance. What I've done is pull out "having
methods" and "having attributes" into two base clasess,
CMOP::HasMethods and ::HasAttributes.
I know we talked about some sort of role-like system for this, but
MI works just as well for this particular usage, and getting role-
like things working in CMOP was proving _very_ difficult because of
bootstrapping issues.
The ::HasMethods class is a parent for ::Package. Since
Moose::Meta::Role already inherits from ::Package, this just works.
The ::HasAttributes class is a parent for ::Class.
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.
In the Moose branch topic/roles-have-real-attributes I've made
Moose::Meta::Role also inherit from CMOP::HasAttributes.
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.
- Stevan
