--- 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. <snip> > 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 composition. 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. 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
