Ovid wrote:
I recently was trying to research some composition issues with roles and one of
the researchers directed me to this paper:
http://scg.unibe.ch/archive/papers/Duca07b-FreezableTrait.pdf
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.
<snip>
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?
