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
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 finally
Mea culpa.
The problem was resolved by the work done on memory leaks at the
beginning of the year.
I should have changed the ticket - but I havent done this before.
Set the status to Resolved.
Ditto #65957 (I opened two tickets by mistake - new at this game).
Richard
Kyle Hasselbacher via
# New Ticket Created by Carlin Bingham
# Please include the string: [perl #69760]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69760 >
[00:19] rakudo: class Foo { method bar { Quux.parse('OH
HAI'); } }; grammar Qu
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #69756]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69756 >
rakudo: multi sub f(0) {}; multi sub f($n) { say $n;
callwith($n - 1) }; f(3)
rakudo 5
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #69762]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69762 >
rakudo: sub foo {}; &foo !~~ Sub
rakudo 3eceb8: OUTPUT«Class P6protoobject already reg
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
--- On Wed, 14/10/09, Jon Lang wrote:
> From: Jon Lang
> 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 T2 { method foo() }
> class
On 2009-Oct-14, at 8:52 am, Ovid wrote:
--- On Wed, 14/10/09, Jon Lang 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 still have a disambigu
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #69766]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=69766 >
rakudo: class A { has &!f; method new(&f) { self.bless(*, :&f) } }
rakudo 3eceb8: OUTP
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 t
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
This is an automatically generated mail to inform you that tests are now
available in t/spec/S06-operator-overloading/sub.t
commit 18aadd8fead78ab26ce3d1fd22f30443fbfd310f
Author: kyle
Date: Wed Oct 14 21:25:41 2009 +
[t/spec] Test for RT 65638
git-svn-id: http://svn.pugscode
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 lex
David Green 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 roles (e.g. Loggin
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 th
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 can
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 Numeri
On 10/14/09, Ovid 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 (if any) and that it can *fr
19 matches
Mail list logo
