Austin Hastings wrote:Jonathan Lang wrote: > role A {has Cat $.x;} > role B {has Dog $.x;} > class Foo {does Cat; does Dog;} > my Foo $bar; > $bar.x; # Is this a Cat or a Dog?
<A12> If, however, two roles try to introduce a method of the same name (for some definition of name), then the composition of the class fails, and the compilation of the program blows sky high--we sincerely hope. It's much better to catch this kind of error at compile time if you can. And in this case, you can. </A12>
Since classes are autogenerating accessors based in data members, it's doubly reasonable to assume that the same solution will apply: conflict -> death.
Note that the problem extends past accessors: a role's methods can access its attributes directly. So:
role A {has Cat $.x; method m1 {return $.x;};} role B {has Dog $.x; method m2 {return $.x;};} class Foo {does Cat; does Dog;} my Foo $bar; $bar.m1; # returns $A::x, right? $bar.m2; # returns $B::x, right?
If the two $.x's are completely equivelent, you end up with redundant data storage.
I'd think, assuming roles are allowed to add attributes (and, if so, I'd argue "what's the difference between a class and a role, then?" but someone'd hit me), that the attribute would be role-specific. In the above case you'd have two separate attributes.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
