Re: Freezing role methods

2009-10-16 Thread Richard Hainsworth
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

Re: Freezing role methods

2009-10-15 Thread Richard Hainsworth
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()

Re: Freezing role methods

2009-10-15 Thread Ovid
--- 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

Re: Freezing role methods

2009-10-15 Thread Matthew Walton
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

Re: Freezing role methods

2009-10-15 Thread Richard Hainsworth
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.

Re: Freezing role methods

2009-10-15 Thread Ovid
--- 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

Re: Freezing role methods

2009-10-14 Thread Jon Lang
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

Re: Freezing role methods

2009-10-14 Thread Ovid
--- 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

Re: Freezing role methods

2009-10-14 Thread David Green
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

Re: Freezing role methods

2009-10-14 Thread TSa (Thomas Sandlaß)
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

Re: Freezing role methods

2009-10-14 Thread Jon Lang
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

Re: Freezing role methods

2009-10-14 Thread David Green
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

Re: Freezing role methods

2009-10-14 Thread Eirik Berg Hanssen
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

Re: Freezing role methods

2009-10-14 Thread Jon Lang
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

Re: Freezing role methods

2009-10-14 Thread Darren Duncan
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

Re: Freezing role methods

2009-10-14 Thread Jon Lang
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;

Re: Freezing role methods

2009-10-14 Thread Mark Morgan
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