On 10/14/09, Ovid <publiustemp-perl6langua...@yahoo.com> wrote: > In short, under the original traits model, you have roles you can't compose > together. The paper argues that in languages which have "public" and > "private" methods, that the composing class is allowed to decide which x() > method it needs (if any) and that it can *freeze* the other x() method. > That is to say, the x() in question would become private and statically > bound to the invocants to ensure that they're always calling the correct > x(). > > How would Perl 6 approach this issue?
Hrm, to clarify for myself, would this imply that roles have a specialised MRO, such that, they would resolve methods as (in order from highest preference to lowest): 1/ Implemented by the class they're composed into. 2/ The role that the called method is defined in. 3/ Any roles that the role the method is called on are composed into. This seems to be the only thing which would make sense. This would avoid unexpected action-at-a-distance, when two roles with similarly-named internal methods (whether public or private) are consumed into the same class, or to avoid roles having to know too much about other roles which aren't composed into the current role's implementations. Mark.
