On Thu, Oct 15, 2009 at 10:07 AM, Ovid <publiustemp-perl6langua...@yahoo.com> wrote: > 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.
What if there are genuinely situations when you cannot combine two roles into the same class? Do all combinations have to be possible? As TSa said, a role depending on one of its own public methods is asking for trouble when it gets combined with something else with a conflicting method, so perhaps what we should really be thinking about is how to write well-behaved roles.
