Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibly inconsistent behaviour in mixing-in of 'handles' #894

Closed
p6rt opened this issue Apr 16, 2009 · 12 comments
Closed

Possibly inconsistent behaviour in mixing-in of 'handles' #894

p6rt opened this issue Apr 16, 2009 · 12 comments

Comments

@p6rt
Copy link

p6rt commented Apr 16, 2009

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

Searchable as RT64766$

@p6rt
Copy link
Author

p6rt commented Apr 16, 2009

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
Copy link
Author

p6rt commented Aug 13, 2010

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
Copy link
Author

p6rt commented Aug 13, 2010

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

@p6rt
Copy link
Author

p6rt commented May 29, 2012

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
Copy link
Author

p6rt commented May 30, 2012

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
Copy link
Author

p6rt commented Dec 18, 2015

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
Copy link
Author

p6rt commented Dec 18, 2015

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

@p6rt
Copy link
Author

p6rt commented Sep 27, 2016

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
Copy link
Author

p6rt commented Sep 27, 2016

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

@p6rt
Copy link
Author

p6rt commented Sep 28, 2016

From @usev6

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

1 similar comment
@p6rt
Copy link
Author

p6rt commented Sep 28, 2016

From @usev6

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

@p6rt
Copy link
Author

p6rt commented Sep 28, 2016

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

@p6rt p6rt closed this as completed Sep 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant