> > > 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?
My personal use-case is covered by the hash version at the moment. But the use-case for delegation to another object is similar: Wherever you want to delegate some functionality to another object, but hide this in your api, and at the same time rely on object introspection for some general features. At the minimum this is useful if you have to hide a new delegation because of backwards compatibility. But I can see arguments to hide delegation in new APIs too. > > 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. For delegating to hashes your name is perfect. I wonder if it isn't a little misleading when delegating to another object, which I still could decide to implement some day. Greetings Nathan
