Hi,

On Fri, 27 Nov 2009 21:21:53 -0500 Stevan Little wrote:

> - Would you expect this work with Native traits? If so how would you  
> expect it to work?

No, but that's no problem here - the Native traits do not work with
arrayrefs or regexes, so it's no much difference that they do not work
with these enhanced arrayrefs. (Here 'do not work' means that it asserts
that the value of 'handles' is a hashref.)

> - What is the order of evaluation? Is that even relevant? What might  
> be some issues that would bring up?

No, it's irrelevant to my knowledge. (No more than the order of the
element is relevant for the arrayref form.)

> - Would you support having multiple regexprs in the list? Again how  
> would order of evaluation be handled? What if it matches for one  
> regexpr and not for another? Is this a conflict? or do we accept both?

Yes, I would. A method is included if it's present in the list as a
string, or if at least one regex matches it.

> - How do you handle methods which match the strings and also match the  
> regexpr? Is the method list made unique before applying? Same for  
> multiple regexprs?

First see my answer for the previous question. The list is not made
unique, though probably it should be. Anyways, the user can already pass
non-unique lists with the arrayref form:

has foo => (
    isa => 'HashRef[Foo]',
    is => 'rw',
    handles => [
        'bar',
        'quux',
        'bar',
    ],
);

If we demand that the arrayref+regex form always results in an unique
list, then we also have to make sure that the arrayref results in an
unique list (as the arrayref is a special form of the arrayref+regex
form - when the number of regexes is 0).

> I would like to make sure these items are thought through before we  
> consider putting this feature in the core. I will also point out that  
> it is the policy (in Moose::Manual::Contributing) that something like  
> this be first tested out in a MooseX:: module.

Ok, I already read that document before I set off hacking on this, but I
was not sure if that applies for this feature (it breaks no existing code
to my knowledge, and is just the logical extrapolation of some other
feature).

Then I'll create Just Another CPAN Module That Nobody Uses But Me.. :-)

norbi

Reply via email to