On Sat, 4 Oct 2014, Karen Etheridge wrote:

On Fri, Oct 03, 2014 at 09:28:22PM +0000, John Macdonald wrote:
If you have a role and its consumer both specify the same attribute name 
(neither one using +name) there is no complaint from Moose and the second one 
encountered is used and the first is ignored.
I tracked this down after getting an error that the predicate method was not 
found - that was defined in the version of the attribute that was discarded 
without notice.
Could there be something done in the 'has' handler to detect such duplicates 
and give an error rather than this sort of quiet misaction?

This is actually a feature. Roles and subclasses should be able to
completely override an earlier attribute declaration.  There are, of
course, opportunities to make this more clear in documentation...

should be able to != do it silently

I think there's an opportunity to do both here, by bringing Attribute 
consumption more in line with Method consumption by making conflict resolution 
explicit.  Making Attributes entirely Private to both Classes and Roles ala 
p5-mop-redux would be ideal, but if Moose Roles are aiming to become Trait 
compliant, we really need to take this 'order of Role consumption' issue out of 
the equation, and that requires explicit conflict resolution.

As Ovid observed last year in the 2.0800 announcement thread, with virtually no 
response from the list, is that this order of consumption 'feature' goes 
against the very core of what Traits are and how very deliberately this 
solution was chosen.

I've not contributed a line of code yet, and a large reason was last year's 
silence on this topic.  I'd be much more excited about contributing and helping 
implement this stuff if Moose was looking to become Trait compliant, but if 
it's not then it won't pay off the type of returns that are possible with 
Traits and I have a hard time justifying the investment in time.

No offense, IMHO etc. - just hoping that people think about this if not discuss 
it publicly here on the list :-)  Cheers,

--
Niall Young
ni...@iinet.net.au

Reply via email to