- Original Message
> From: Jon Lang
> Right. But as they were originally conceived, they were interfaces
> that could also handle code reuse, rather than units of code reuse
> that could also be used as interfaces. From this perspective, it
> makes perfect sense that a role's methods
Daniel Ruoso wrote:
> Jon Lang wrote:
>> The key to understanding roles is to note that roles don't implement
>> methods; classes implement methods.
>
> Er, while I see your point, Roles are not just interfaces... they are OO
> components that can be plugged into other classes. They often are used
On Jul 12, 2009, at 20:15 , David Green wrote:
sub nighttime (Canine $rover) { $rover.bark if any(burglars()); }
(...)
3) $rover acts like a Canine, but the rest of the original $dogwood
arg (the Tree parts) are still there; they just aren't used unless
somehow explicitly brought out; for
On 2009-Jul-12, at 12:43 pm, Daniel Ruoso wrote:
role R1 {
method foo() {...} # degenerates to interface
}
Just wondering: since merely declaring an interface will be common
enough, should we be able to say simply "method foo;" inside a role,
and drop the {...}?
class Bla does R2 {
m
On 2009-Jul-10, at 4:37 pm, Jon Lang wrote:
This is one of the distinctions between role composition and class
inheritance. With class inheritance, the full tree of inherited
classes is publicly accessible; with role composition, the methods
of the combined role are the only ones that are m
Em Sex, 2009-07-10 às 15:39 -0700, Jon Lang escreveu:
> The key to understanding roles is to note that roles don't implement
> methods; classes implement methods.
Er, while I see your point, Roles are not just interfaces... they are OO
components that can be plugged into other classes. They often
The key to understanding roles is to note that roles don't implement
methods; classes implement methods. Roles define which methods must
be implemented, and suggest ways that they might be implemented;
classes decide which implementation to use. Anything that breaks this
paradigm is a Bad Thing.
The key to understanding roles is to note that roles don't implement
methods; classes implement methods. Roles define which methods must
be implemented, and suggest ways that they might be implemented;
classes decide which implementation to use. Anything that breaks this
paradigm is a Bad Thing.
On 2009-Jul-7, at 5:28 am, Jonathan Worthington wrote:
The spec is right in that you need to write a method in the class
that decides what to do. This will look something like:
method fuse() { self.Bomb::fuse() }
That makes sense for using the combined role on its own, but can we
still
Jonathan Worthington wrote in "YAPC::EU and Perl 6 Roles":
> More fitting to me would be an adverb to the does trait modifier...
>
> class C does R1 :without does R2 :without { ... }
>
> The thing is that in this case, does the class actually do R1 and R2? If you
> are going to derive an anonymous
10 matches
Mail list logo
