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()
--- 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
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
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, 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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #69798]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69798 >
hooray for runnable, concrete examples!
indeed, moritz_++
don't praise me until you a
This is an automatically generated mail to inform you that tests are now
available in t/spec/S06-multi/type-based.t
commit fff5be9d99e2e6824395bb2183062e57c746336c
Author: moritz
Date: Thu Oct 15 17:19:52 2009 +
[t/spec] tests for RT #69798
git-svn-id: http://svn.pugscode.org
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
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
