Re: overlapping attributes not detected

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
[email protected]