On Thu Apr 16 06:23:35 2009, masak wrote:
> OH HAI from NPW::2009.
>
> In Rakudo 2c13d6c, the 'handles' instruction on attributes in roles
> don't override those of the class it mixes in.
>
> $ perl6 -e 'class A { method foo { say "OH HAI" }; method aie { say
> "AIE!" } }; role B { has A $.bar handles * }; class C does B { has A
> $.bar handles "foo" }; C.new.aie'
> Could not locate a method 'aie' to invoke on class 'C'.
> [...]
>
> I don't think that the above case is mentioned in the spec, but by the
> principle of mixins adding attributes consistent with the existing
> ones, the above should dispatch to A.aie(), instead of failing.
>
> By the same token, I guess the following should actually be an error:
>
> $ perl6 -e 'class A { method foo { say "OH HAI" }; method aie { say
> "AIE!" } }; role B { has A $.bar handles "aie" }; class C does B { has
> A $.bar handles "foo" }; C.new.aie'
> AIE!
>
> Finally, if the two 'handles' RHSes were regular expressions instead
> of strings, I guess all bets are off and we should fail just in case.
> At least unless we can introspect regexes.
The reasoning is a bit off here. Attributes declared in roles are meant to
behave much like if they were declared in the class itself. That means that
you'd be declaring two attributes $!bar in both of these examples. This today
does indeed correctly report a conflict - for both of the code examples.
That did leave the issue that we had no tests for if wildcard and literal
handles on attributes in roles took effect. I wrote some tests to check they
do, and indeed that works out. See the tests added to S14-roles/composition.t
in 5a0c386 for the details.
