--- On Thu, 15/10/09, Richard Hainsworth <rich...@rusrating.ru> wrote:

> From: Richard Hainsworth <rich...@rusrating.ru>
> > 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.
> Am I wrong in thinking the spec answers the question?

Reading the paper I linked to could help to clarify the issue.  In short, there 
are times under my current understanding of roles where you *can't* resolve the 
conflicts.  Two roles, each providing and dependent upon a method x(), such 
that if either tries to use the other's "x()", the code will fail. Thus, you 
cannot choose one x() over the other.

"frozen" traits suggests that the composing class determine which x() it wants 
and statically binding the other x() to its role, thus guaranteeing that no 
role can get the wrong x(), but still allowing classes full control over their 

I need to read the other responses more closely to understand their reasoning.  
So far, they seem wrong to me, but that's probably because I'm not reading them 
closely enough.

Buy the book         - http://www.oreilly.com/catalog/perlhks/
Tech blog            - http://use.perl.org/~Ovid/journal/
Twitter              - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Reply via email to