Front page | perl.moose |
Postings from December 2009
Re: Attributes have real roles - take 2
From: Stevan Little
December 28, 2009 08:47
Re: Attributes have real roles - take 2
Message ID: 059D5140-82A9-489D-91AA-26860C4C513F@iinteractive.com
On Dec 26, 2009, at 2:22 PM, Dave Rolsky wrote:
> Based on discussion with Stevan, I've made some major changes to my
> 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
> 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
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.
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::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:
> 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