overlapping attributes not detected

[John Macdonald]

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?

John Macdonald
Software Engineer

Ontario Institute for Cancer Research
MaRS Centre

661 University Avenue

Suite 510
Toronto, Ontario

Canada M5G 0A3

Tel:

Email: John.Ma...@oicr.on.ca

Toll-free: 1-866-678-6427
Twitter: @OICR_news

www.oicr.on.ca

This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

[Karen Etheridge]

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...

[John Macdonald]

I'd rather see it as has '-XXX' to override, has '+XXX' to augment, and has 'XXX' to create a new attribute, with an error if an unsigned creation had a conflict.

That provides the feature when it is desired without providing an action ata distance bug when it is unexpected.

John Macdonald
Software Engineer

Ontario Institute for Cancer Research
MaRS Centre

661 University Avenue

Suite 510
Toronto, Ontario

Canada M5G 0A3

Tel:

Email: John.Ma...@oicr.on.ca

Toll-free: 1-866-678-6427
Twitter: @OICR_news

www.oicr.on.ca

This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

________________________________________
From: Karen Etheridge [pe...@froods.org]
Sent: October 4, 2014 2:47 PM
To: mo...@perl.org
Subject: Re: overlapping attributes not detected

[Karen Etheridge]

On Sat, Oct 04, 2014 at 08:02:05PM +0000, John Macdonald wrote:
> I'd rather see it as has '-XXX' to override, has '+XXX' to augment, and has 'XXX' to create a new attribute, with an error if an unsigned creation had a conflict.
> That provides the feature when it is desired without providing an action ata distance bug when it is unexpected.

Perhaps, but it's far too late to make that change now without breaking
everyone's code :)

[Niall Young]

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

[Niall Young]

On Sat, 4 Oct 2014, Karen Etheridge wrote:

You can't maintain 'XXX' to silently override as is the current behaviour, and introduce more prefixes to handle the new behaviours?

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