Skip Menu |
Report information
Id: 114930
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] Multi method in class implementing stubbed method in role causes bogus "must be implemented" error in Rakudo
Date: Sun, 16 Sep 2012 20:48:41 +0200
To: rakudobug [...] perl.org
From: Carl Mäsak <cmasak [...] gmail.com>
Download (untitled) / with headers
text/plain 1.4k
<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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org