Larry Wall wrote:
> On Fri, Apr 23, 2004 at 02:37:58PM -0700, Jonathan Lang wrote:
> : 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.
>
> Actually, it'd blow up at composition time anyway, since there's a
> default readonly accessor for each $.x variable.
OK; so add "method x {...};" to class Foo to keep it from blowing up. Foo
still has to track two scalars internally.
Actually, it's worse than that: let's add "has Elephant $.x;" to Foo
instead. Since class trumps role, does $bar.m1 now work with an Elephant,
or does it still work with a Cat?
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
