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
Summary: the original trait researches did intend for class methods to have
precedence over roles methods in composition, but they had no intention that it
do so silently. In fact, they go on to say that doing so silently would be a
bad idea. One way of resolving this is to do what Sun
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
13 matches
Mail list logo
