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
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 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
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
Ovid wrote:
--- On Thu, 15/10/09, Richard Hainsworth rich...@rusrating.ru 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.
--- On Thu, 15/10/09, Richard Hainsworth rich...@rusrating.ru wrote:
From: Richard Hainsworth rich...@rusrating.ru
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
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
Ovid wrote:
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
--- On Wed, 14/10/09, Jon Lang datawea...@gmail.com wrote:
From: Jon Lang datawea...@gmail.com
The initial possibility that springs to mind would be to
use longnames
to disambiguate between the two options - specifically, by
means of
the invocant:
role T1 { method foo() }
role
On 2009-Oct-14, at 8:52 am, Ovid wrote:
--- On Wed, 14/10/09, Jon Lang datawea...@gmail.com wrote:
The initial possibility that springs to mind would be to use
longnames to disambiguate between the two options - specifically,
by means of the invocant:
...or something to that effect. You'd
HaloO,
On Wednesday, 14. October 2009 12:18:30 Ovid wrote:
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.
I consider the
David Green wrote:
Or to look at it the other way around: Since we refer to things by name,
those names have to be unique everywhere; so let's start out with long,
fully-qualified names everywhere: $dog.Dog::bark(), $tree.Tree::bark(),
$i.Int::succ, etc. Now everything's fine -- except that
On 2009-Oct-14, at 2:00 pm, Jon Lang wrote:
David Green wrote:
On the other hand, $dogwood.Dog::bark cannot be simplified by
leaving out the Dog:: because then it would be ambiguous.
On the gripping hand, if we have a function train(Dog $d), then we
can safely assume that within the
David Green david.gr...@telus.net writes:
The soft way -- being able to cast $dogwood as a Dog and treat it
unambiguously so, then to do the same thing treating it as a Tree
object -- is the most flexible. Split-personality Dogs may be rare,
but I can imagine wanting to call common utility
David Green wrote:
Jon Lang wrote:
David Green wrote:
On the other hand, $dogwood.Dog::bark cannot be simplified by leaving out
the Dog:: because then it would be ambiguous.
On the gripping hand, if we have a function train(Dog $d), then we can
safely assume that within the lexical scope of
Jon Lang wrote:
Here, we need a bit of a clarification: are we talking roles or
classes? Real example: Numeric is a role; Num is a class. Both can
be used in signatures; but only classes can be used to create objects.
That is, my Num $x; works; but my Numeric $x; doesn't. As such,
you cannot
Darren Duncan wrote:
Jon Lang wrote:
Here, we need a bit of a clarification: are we talking roles or
classes? Real example: Numeric is a role; Num is a class. Both can
be used in signatures; but only classes can be used to create objects.
That is, my Num $x; works; but my Numeric $x;
On 10/14/09, Ovid publiustemp-perl6langua...@yahoo.com wrote:
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
18 matches
Mail list logo
