> 
> > I had to copy-paste two methods from
> > Moose::Meta::Method::Constructor with
> > very little changes. Any interest in changing Moose to avoid this?
> > Any ideas
> > how to do this properly?
> 
> Would need to know more of what it is you actually did to know if we
> could do something in the Moose guts. And of course topic branches are
> *always* welcome :)

I had to overwrite _generate_slot_assignment and _generate_triggers, which are 
the only methods of of Meta::Method::Constructor which use the instance meta 
object to access slots. My versions are nearly identical. Imho 
Method::Constructor should not assume an exact way how the Attribute uses 
Meta::Instance to store itself in the object, but rather let the Attribute 
decide.

I went ahead and tried to make the needed changes myself. The resulting diff is 
at 
http://github.com/xabbu42/moose/commit/a0cfca605c06d3e5c3750b6dc774e9b806bc5dd7

I get some failing tests because the M::Meta::Method::* in Moose apparently 
need to work with Class::MOP::Attribute too. So for this approach to work, the 
diff for M::Meta::Attribute actually belongs into Class::MOP::Attribute.

Of course I don't know at all if this is the right approach, but you see what 
it is I want to do.

By the way, why is sometimes $attr->slots and sometimes $attr->name used?

> 
> I wonder how much you looked into the Instance protocol? Overriding
> Meta::Instance classes is usually where people go when they want to
> affect slot storage. I am not sure if it would work in your case, but
> just wanted to make sure you knew about it.

I looked into it, but an implementation of this in Meta::Instance is imo less 
clean. The Instance object doesn't know anything about attributes anymore, 
only slot names and how to access them. I'd have to find the Attribute object 
for a particular slot again to find out if this attribute is delegated or not.

A second point is, that my Module actually should work with an arbitrary 
Meta::Instance (untested), since it doesn't care how the hash delegating to is 
actually saved in the object. It just uses the Meta::Instance to get the hash 
out of the object and then accesses keys in this hash.

Greetings
Nathan

Reply via email to