Possibly inconsistent behaviour in mixing-in of 'handles'

[p6rt]

Migrated from rt.perl.org#64766 (status was 'resolved')

Searchable as RT64766$

[p6rt]

From @masak

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.

[p6rt]

From sohtil@gmail.com

Currently both cases cause an error​:

(Note​: It would be awesome if the error message mentioned the
name of the class and the role.)

$ ./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'
===SORRY!===
Attribute '$!bar' already exists in the class, but a role also wishes to
compose it

$ ./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'
===SORRY!===
Attribute '$!bar' already exists in the class, but a role also wishes to
compose it

$ ./perl6 --version

This is Rakudo Perl 6, version 2010.07-113-gc41bcd7 built on parrot
2.6.0 r48341

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @diakopter

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.

this is now fixed. marking testneeded.

17​:12 <diakopter> r​: 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
17​:12 <p6eval> rakudo 024843​: OUTPUT«===SORRY!===␤Attribute '$!bar'
already exists in the
  class 'C', but a role also wishes to compose it␤»

[p6rt]

From @diakopter

On Tue May 29 15​:13​:18 2012, diakopter 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.

this is now fixed. marking testneeded.

17​:12 <diakopter> r​: 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
17​:12 <p6eval> rakudo 024843​: OUTPUT«===SORRY!===␤Attribute '$!bar'
already exists in the
class 'C', but a role also wishes to compose it␤»

unmarking testneeded; the classname is now mentioned in the error, but
the first complaint is not resolved.

[p6rt]

From @jnthn

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.

[p6rt]

@jnthn - Status changed from 'open' to 'resolved'

[p6rt]

From @coke

On Fri Dec 18 08​:26​:09 2015, jnthn@​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

[p6rt]

@coke - Status changed from 'resolved' to 'open'

[p6rt]

From @usev6

With rakudo commit 5435f32949 the test passes again on JVM. I'm closing this ticket.

[p6rt]

From @usev6

With rakudo commit 5435f32949 the test passes again on JVM. I'm closing this ticket.

[p6rt]

@usev6 - Status changed from 'open' to 'resolved'