On Nov 1, 2009, at 7:38 PM, Nathan Gass wrote:
Hello list
Hello Nathan,
I hope this does not result in a double post, since I first send the
mail with
the wrong from address.
I only got/saw one copy myself.
I got the basics of delegating an Attribute to a Hash stored in
another
attribute working (http://github.com/xabbu42/MooseX-Attribute-Delegated
). But
starting to write the module raised a lot of questions:
Should I rather implement this as a new attribute meta class instead
of a
role, considering I mostly overwrite methods and the module
currently probably
does not work well together with other extensions changing the way an
attribute is saved in the object?
No, a role is the way to do it. There is not guarantee that any role
extension work with any other extension, but a metaclass will never
work with another metaclass.
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 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.
Should I avoid MooseX::Declare if I want to upload this to CPAN?
Yes, only because you will alienate regular Moose users or people
concerned with startup time (Moose is slow, but MX::Declare is slower
still). I am confident that MooseX::Declare will eventually become
just plain Moose, but probably not until some of the funkier
Devel::Declare guts make their way into perl itself.
I'd like to add delegation to another Moose object too. As I see it,
this
should respect all the settings (trigger, isa ...) for the attribute
in the
delegated object and all settings in the delegating attribute
definition. For
this to work I'll have to create an instance of the accessor meta
class for
the attribute delegated to, and use this to create an accessor with
implements
all settings from both attribute definitions. Is this correct?
Any opinions on the correct behavior of the constructor?
Honestly, this sounds like overkill to me, while I can easily see the
usefulness of this feature inside a single class, I fear that making
it span between two classes is maybe going too far. Do you have a real-
world use-case for this?
And lastly, I am not so sure about the name you have chosen. Only
because Moose already has a delegation feature for attributes and it
does something very different then this does. I am not sure what to
call it, but perhaps something like
MooseX::Attribute::DelegatedStorage, which gives a little more of a
clue as to what exactly it is doing.
- Stevan
