- Original Message
From: Jon Lang datawea...@gmail.com
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
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
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
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 {
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
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
for
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
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.
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 :withoutfoo bar does R2 :withoutbaz { ... }
The thing is that in this case, does the class actually do R1 and R2? If you
are going to derive an
10 matches
Mail list logo
