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.
Then again, this may be more of a quirk than a problem...
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
