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.

The only way to handle this appears to be renaming one of the x() methods and 
trying to track down all code which relies on it and changing it.  This 
essentially violates the problem we're trying to solve with traits, er, roles.

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?

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