On Mon, Nov 9, 2009 at 5:58 PM, Dave Rolsky <auta...@urth.org> wrote:
> On Mon, 9 Nov 2009, Jesse Luehrs wrote:
>
>>> My concern is that the instance meta-object is actually associated with
>>> the meta-class, not with the attribute meta-object so by pushing this in
>>> here it will make things more confusing.
>>
>> The reasoning I had for thinking it was reasonable is that the
>> meta-attribute already has get_value, set_value, etc, so I don't see why
>> it shouldn't also control the inline versions of those. It would
>> probably make things simpler for attributes that wanted to use a
>> different slot configuration than we have by default.
>
> But isn't that what the meta-instance is for?
>
> It seems very confusing to allow both the meta-attr _and_ meta-instance to
> mediate how slots are handled.
>
> It seems like this really isn't the meta-attr's responsibility anyway. The
> existing get_value, set_value stuff just delegates to the meta-instance for
> actual slot access.
>
> This whole thing seems somewhat wrong.
>
> It'd really help if there was an example of where this is needed.
The problem isn't really the slot-access, everybody I think rightly
agrees that lives in the Instance metaclass. The problem is the
in-lining code no? Who should be responsible for generating it, the
Attribute or the Instance meta class? I'm not sure that there is a
"correct" answer if those are the only choices.
The use case if I recall was that Nathan (?) wanted to make Attributes
who's slots were themselves stored in other Attributes (ie $foo->bar
is stored in $foo->baz->{bar}). This is I think what
MooseX::Attribute::Delegated does. You'd have to see the other thread
though to be sure I'm not on crack there.
-Chris
