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()
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
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
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
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
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
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 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
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
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
--- 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
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
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
18 matches
Mail list logo
