On Fri Dec 18 08:26:09 2015, jn...@jnthn.net wrote:
> 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.
Tests fail on JVM - re-opening ticket, marking JVM only. Fudged test.
--
Will "Coke" Coleda
