# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #114930]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114930 >
<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.
