Ovid wrote:
I recently was trying to research some composition issues with roles and one of 
the researchers directed me to this paper:


Basically, the problem they have is this "T1" (Trait 1) and "T2" each implement a public "x()" 
method and other methods in T1 and T2 rely on their respective versions of x() and trying to rely on another version breaks those 
methods. When class "C" tries to compose these roles, it has a problem.  It can't exclude one "x()" because 
that breaks the role which needs the excluded x().  It can't override x() because you'll likely break both roles.  You *could* 
(this wasn't explained in the paper) extract those methods into C::x(), check your callers and dispatch as appropriate, but that 
would get very problematic, particularly with roles composed of other roles.
How would Perl 6 approach this issue?
S14 states:
"Roles may be composed into a class at compile time, in which case you get automatic detection of conflicting methods. A role may also be mixed into a class or object at run time to produce an anonymous derived class with extra capabilities, but in this case conflicting methods are overridden by the new role silently. In either case, a class is necessary for instantiation--a role may not be directly instantiated."

This indicates to me that for perl6 the conflict is detected and reported to the programmer to resolve. The compiler is not required to resolve the conflict.

Later S14 has:
"There are several ways to solve method conflicts. The first is simply to write a class method that overrides the conflicting role methods, perhaps figuring out which role method to call.

Alternately, if the role's methods are declared |multi|, they can be disambiguated based on their long name. If the roles forget to declare them as multi, you can force a multi on the roles' methods by installing a proto stub in the class being constructed:

   proto method shake {...}


Am I wrong in thinking the spec answers the question?

Reply via email to