Skip Menu |
 

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 100723
Status: new
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: John.Macdonald [...] oicr.on.ca
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: nested Roles broken on requires
Date: Fri, 5 Dec 2014 17:28:45 +0000
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
From: John Macdonald <John.Macdonald [...] oicr.on.ca>
Download (untitled) / with headers
text/plain 3.4k
If a role wishes to consume another role as part of its implementation, and the consumed role has a 'requires' that must be provided; the consuming role can be written as a self-contained role. The search for 'requires' values is done in the grand(n)parent consumer (the top level consumer which is not a role). Attributes and methods provided by the parent role do not get installed into the top level object until the end of processing of the 'with' statement. So, they have not yet been installed at the point when the parent role tries to consume the child role. The only way to make it work is for the top level object to consume the parent role, and then, in a separate 'with' statement, consume the child role. (Even listing both the parent and the child in the same 'with' statement does not work - the parent's attributes/methods are not installed when the child 's 'requires' statement is processed.) This breaks encapsulation badly. Every consumer of the parent role must be coded to provide the child role that the parent needs for its internal implementation, and must provide it in a separate with statement. If the parent role is changed to use a different implementation, then all consuming object definitions must be found and fixed to deal with the revised internal needs of the consumed role. I suspect that this problem is inherent in the way roles have been implemented - the attributes and methods of a collection of roles are only inserted into the final parent after they have been fully processed. That suggests that fixing it may cause existing code to break. I'd be happy to be wrong about this though, and see someone find a safe way of fixing the problem. In the attached tar, BRole.pm is the child role ARole.pm is the parent role written in a fully encapsulated way ARoleNoWith.pm is the same role, excluding the 'with' statement consuming BRole ABRole.pm is a grandparent role that tries to express the separated 'with' statement requirement to provide the encapsulation again test1.pl is the way the non-role top level consumer "should" be written - only requesting the role that it is actually using - it fails because ARole's attempt to consume BRole complains about the requirement missing from 'main' - it fails because ARole|BRole have a requirement that isn't provided in 'main' test2.pl re-writes the top level consumer to "know" that ARole also implies a need for BRole but using a single 'with' statement test3.pl re-writes the top level consumer with the addition implementation knowledge that the two roles must be consumed separately and in the right order - it compiles correctly test4.pl uses the ABRole attempted workaround - it again gets the complaint thatABRole has a requirement that must be provided in 'main' John Macdonald Software Engineer Ontario Institute for Cancer Research MaRS Centre 661 University Avenue Suite 510 Toronto, Ontario Canada M5G 0A3 Tel: Email: John.Macdonald@oicr.on.ca Toll-free: 1-866-678-6427 Twitter: @OICR_news www.oicr.on.ca<http://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.
Download nestedroles.tar.z
application/x-compress 459b

Message body not shown because it is not plain text.

Subject: RE: [rt.cpan.org #100723] AutoReply: nested Roles broken on requires
Date: Tue, 16 Dec 2014 20:16:36 +0000
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
From: John Macdonald <John.Macdonald [...] oicr.on.ca>
Download (untitled) / with headers
text/plain 5.4k
There is a workaround suggested by Ovid in: http://blogs.perl.org/users/ovid/2014/12/the-mooserole-required-attributes-bug.html Simply add: sub attribute_name; in the role that defines the attribute that is required by a nested role. While a full solution would be nice, documenting this in the description of 'requires' (and perhaps also in the error message for a requires failure) would be adequate to make this far less urgent. John Macdonald Software Engineer Ontario Institute for Cancer Research MaRS Centre 661 University Avenue Suite 510 Toronto, Ontario Canada M5G 0A3 Tel: Email: John.Macdonald@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. Show quoted text
________________________________________ From: Bugs in Moose via RT [bug-Moose@rt.cpan.org] Sent: December 5, 2014 12:28 PM To: John Macdonald Subject: [rt.cpan.org #100723] AutoReply: nested Roles broken on requires Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "nested Roles broken on requires", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.cpan.org #100723]. Your ticket is accessible on the web at: https://rt.cpan.org/Ticket/Display.html?id=100723 Please include the string: [rt.cpan.org #100723] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, bug-Moose@rt.cpan.org ------------------------------------------------------------------------- If a role wishes to consume another role as part of its implementation, and the consumed role has a 'requires' that must be provided; the consuming role can be written as a self-contained role. The search for 'requires' values is done in the grand(n)parent consumer (the top level consumer which is not a role). Attributes and methods provided by the parent role do not get installed into the top level object until the end of processing of the 'with' statement. So, they have not yet been installed at the point when the parent role tries to consume the child role. The only way to make it work is for the top level object to consume the parent role, and then, in a separate 'with' statement, consume the child role. (Even listing both the parent and the child in the same 'with' statement does not work - the parent's attributes/methods are not installed when the child 's 'requires' statement is processed.) This breaks encapsulation badly. Every consumer of the parent role must be coded to provide the child role that the parent needs for its internal implementation, and must provide it in a separate with statement. If the parent role is changed to use a different implementation, then all consuming object definitions must be found and fixed to deal with the revised internal needs of the consumed role. I suspect that this problem is inherent in the way roles have been implemented - the attributes and methods of a collection of roles are only inserted into the final parent after they have been fully processed. That suggests that fixing it may cause existing code to break. I'd be happy to be wrong about this though, and see someone find a safe way of fixing the problem. In the attached tar, BRole.pm is the child role ARole.pm is the parent role written in a fully encapsulated way ARoleNoWith.pm is the same role, excluding the 'with' statement consuming BRole ABRole.pm is a grandparent role that tries to express the separated 'with' statement requirement to provide the encapsulation again test1.pl is the way the non-role top level consumer "should" be written - only requesting the role that it is actually using - it fails because ARole's attempt to consume BRole complains about the requirement missing from 'main' - it fails because ARole|BRole have a requirement that isn't provided in 'main' test2.pl re-writes the top level consumer to "know" that ARole also implies a need for BRole but using a single 'with' statement test3.pl re-writes the top level consumer with the addition implementation knowledge that the two roles must be consumed separately and in the right order - it compiles correctly test4.pl uses the ABRole attempted workaround - it again gets the complaint thatABRole has a requirement that must be provided in 'main' John Macdonald Software Engineer Ontario Institute for Cancer Research MaRS Centre 661 University Avenue Suite 510 Toronto, Ontario Canada M5G 0A3 Tel: Email: John.Macdonald@oicr.on.ca Toll-free: 1-866-678-6427 Twitter: @OICR_news www.oicr.on.ca<http://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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.