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.
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?
Cheers,
Ovid
--
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
