Arising out of "Freezing Roles" is a related question.
Suppose I download a module from CPAN with a role I want to use, but it
introduces a method that I want that is in conflict with an existing
method (say one taken from another CPAN module).
How should the method be aliased to prevent it f
Ovid wrote:
At the BBC, we never encounter this because semantically different methods are
renamed and semantically identical methods are refactored (aliasing and
excluding being code smells). However, if roles start making their way on to
the CPAN, you won't necessarily have control over the
--- On Thu, 15/10/09, Richard Hainsworth wrote:
> From: Richard Hainsworth
> But the assumption in the paper is that the "class
> composer" resolves the conflict, without further programmer
> intervention. The perl6 spec does not require the class
> composer to resolve the conflict only to dete
Ovid wrote:
--- On Thu, 15/10/09, Richard Hainsworth wrote:
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 thin
On Thu, Oct 15, 2009 at 10:07 AM, Ovid
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
--- On Thu, 15/10/09, Richard Hainsworth wrote:
> From: Richard Hainsworth
> > 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
Ovid wrote:
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()
