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

Multi method in class implementing stubbed method in role causes bogus "must be implemented" error in Rakudo #2901

Closed
p6rt opened this issue Sep 16, 2012 · 3 comments

Comments

@p6rt
Copy link

p6rt commented Sep 16, 2012

Migrated from rt.perl.org#114930 (status was 'new')

Searchable as RT114930$

@p6rt
Copy link
Author

p6rt commented Sep 16, 2012

From @masak

<skids> speaking of which, if you have a role that defines a required
api e.g. role R1 { method m { ... } }, is there a way to let roles
satisfy it with either a multi or a non-multi .m ?
<jnthn> skids​: Doesn't that already work?
<skids> Don't think so, lemme golf a bit...
<skids> Hrm, apparently it works with roles/cronies but not directly
with classes...
<skids> r​: role A { method m (*@​a) { ... } }; class C does A { multi
method m (*@​a) { "OHAI".say } }; my C $c .= new(); $c.m(3);
<p6eval> rakudo 5aa57b​: OUTPUT«===SORRY!===␤Method 'm' must be
implemented by C because it is required by a role␤»
<skids> r​: role A { method m (*@​a) { ... } }; role B { multi method m
(*@​a) { "OHAI".say } }; class C does B { }; my C $c .= new(); $c.m(3);
<p6eval> rakudo 5aa57b​: OUTPUT«OHAI␤»
<jnthn> skids​: Ah...I think you found a bug
<jnthn> Ordering problem, I guess...
* masak submits rakudobug
<masak> r​: role R { method m (*@​a) { ... } }; class C does R { multi
method m (*@​a) {} }
<p6eval> rakudo 5aa57b​: OUTPUT«===SORRY!===␤Method 'm' must be
implemented by C because it is required by a role␤»
<masak> writing useful RT ticket titles causes me to stop and think
what the ingredients in a bug might be :)
<jnthn> Well, the bug hangs off an ordering issue
<jnthn> We compose roles, *then* take the bunch of multis we know
about and auto-gen protos
<jnthn> That, unfortunately, means that those auto-gen'd protos aren't
there in time for the check.

@p6rt p6rt added the Bug label Jan 5, 2020
@usev6
Copy link

usev6 commented Feb 19, 2023

This seems to work nowadays:

$ m 'role R { method m (*@a) { ... } }; class C does R { multi method m (*@a) {} }; say "alive"'
alive
$ ./rakudo-m -e 'role R { method m (*@a) { ... } }; class C does R { multi method m (*@a) { "OHAI".say } }; my C $c .= new(); $c.m(3)'
OHAI

According to bisectable6 this has been fixed back in 2018 with rakudo/rakudo@fd5d5bdfb9. (That commit mentions a more recent Rakudo issue (which looks very similar to this old issue): rakudo/rakudo#2386.)

Probably it would make sense to add a test to roast for this issue. Tagging "rtestneeded"

usev6 added a commit to usev6/roast that referenced this issue Feb 19, 2023
usev6 added a commit to usev6/roast that referenced this issue Feb 20, 2023
@usev6
Copy link

usev6 commented Feb 21, 2023

We have a test now, added with Raku/roast@1c7224ada5. (With the help of (committable6)[https://colabti.org/irclogger/irclogger_log/raku-dev?date=2023-02-20#l17] I figured out that the slurpy parameter is not relevant for the bug, so I left it out.)

I'm closing this issue as resolved.

@usev6 usev6 closed this as completed Feb 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants