On Dec 26, 2009, at 2:22 PM, Dave Rolsky wrote:
Based on discussion with Stevan, I've made some major changes to my
branches.
In the CMOP topic/mi-methods-attributes branch, the HasMethods and
HasAttributes classes are now under CMOP::Mixin::.
They still inherit from CMOP::Object, because they need to have a -
>meta method. I could change that (maybe have a separate CMOP::Mixin
parent?), but that's a small detail.
Why not just implement our own ->meta? I am just not sure that these
mixins should every be instantiated and so should not have a
constructor method (even if it is just _new). It is a small issue, but
I worry about method inheritance problems when you have MI and diamond
hierarchies, so why have methods if you don't actually need them /
plan to use them / want anyone else to use them?
In this branch, there is also a new mixin class with the unfortunate
name of CMOP::Mixin::AttributeBase. I hate calling it "Base" so
suggestions are welcome. Basically, I've moved the attributes of the
meta-attribute class into a separate mixin for the benefit of role
attributes.
This AttributeBase class is all properties and very little behavior.
The behavior is still mostly in CMOP::Attribute and MM::Attribute.
Again, a better name is welcome, but I think the idea is sound.
Yes, agreed the idea is sound, this basically implements the
introspection interface for a Meta-Attribute. The name does suck
though, perhaps...
Class::MOP::Mixin::AttributeCore
Class::MOP::Mixin::Attribute::Introspection
Class::MOP::Mixin::AttributeAccessors
Again, I am not sure that it makes sense for this to be a subclass of
Class::MOP::Object either, it just seems to add an extra connection
point that is not needed.
CMOP::Object
/ \
CMOP::Attribute \
/ \
Moose::Meta::Attribute Moose::Meta::Role::Attribute
Is a much cleaner hierarchy, and if we treat the Mixin:: classes as
more role like then we can retain this.
In the Moose topic/roles-have-real-attributes branch, I've made a
lot more changes.
Instead of using a trait to make role attributes special, they are
now their own class. The hierarchy for attributes looks like this:
CMOP::Mixin::AttributeBase
/ \
CMOP::Attribute Moose::Meta::Mixin::AttributeBase
\ / \
Moose::Meta::Attribute Moose::Meta::Role::Attribute
Yay, diamond inheritance. Yes, it's disturbing, but if you think of
the mixins as roles it's a little less horrible.
Again, the AttributeBase mixin in Moose captures attribute
properties, while MM::Attribute provides behavior.
The role attribute now knows how to make a "real" attribute for
classes, given an attribute metaclass, like this:
$role_attr->attribute_for_class($attr_metaclass)
This is called during role application to a class, and can _also_ be
called at some other time in order to get more information out of
the role attribute.
By itself, the role attribute doesn't do much, it just captures the
options passed to "has".
This is a little weird, because it means that things like $role_attr-
>reader will generally return undef, because it doesn't process the
"is" option.
You might think "why not just make a real attribute", but the answer
is that without knowing what attribute metaclass to use, making a
real attribute won't get the right answer.
A concrete example of this problem can be seen with MX::FollowPBP.
When that MX is used, it applies a meta-attr trait that changes how
"is" is processed. This means that you can only know the real method
names in the context of a specific "real" attribute metaclass.
This means that introspection on the role attribute is really not
complete unless you can supply an attribute metaclass. However,
given our future goal of generating method conflicts _when applying
role attributes to a class_, this is fine. When we do that
application, we can ask the class for its metaclass, figure out all
the method names that will be generated, and look for conflicts.
Note that this conflict detection is not yet implemented. That's the
next step, but I'd like to get these changes merged as-is.
So please review the above-mentioned branches.
They all look good to me, I think this is a great start towards those
features.
- Stevan
