Skip Menu |
 

This queue is for tickets about the Kavorka CPAN distribution.

Report information
The Basics
Id: 123849
Status: open
Priority: 0/
Queue: Kavorka

People
Owner: Nobody in particular
Requestors: RLANG [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.036
Fixed in: (no value)



Subject: Unable to use Multi Methods in Roles
Download (untitled) / with headers
text/plain 786b
Hi there- It appears that multi subs/methods don't work properly when being composed in roles (Moo::Role). I did a little digging, and it seems that rather than methods being registered under the package name of a role's consumer, they are registered under the package name of the role itself. So when it comes time to look up a method in the dispatch table, we're looking in the wrong package name, and get this error: "did not match any known signature for multi sub" I'm not especially familiar with how Moo::Role works behind the scenes, and so maybe this is unfixable, or undesired. But it seems that if it were fixable, maybe Kavorka::Multi::__gather_candidates would be the place to do it...? Do you have any thoughts on this? (Big fan of Kavorka - thank you!) Ryan Lang
Download (untitled) / with headers
text/plain 1.2k
Example in code: ------ package My::Role; use Moo::Role; use Types::Standard qw/ArrayRef HashRef/; use Kavorka qw/multi method/; multi method process (ArrayRef $x) { say "here" } multi method process (HashRef $x) { say "there" } package My::Consumer; use Moo; with 'My::Role'; __PACKAGE__->process( [] ); # blows up here: Arguments to My::Role::process did not match any known signature for multi sub __PACKAGE__->process( {} ); On Sat Dec 09 15:07:52 2017, RLANG wrote: Show quoted text
> Hi there- > > It appears that multi subs/methods don't work properly when being > composed in roles (Moo::Role). > > I did a little digging, and it seems that rather than methods being > registered under the package name of a role's consumer, they are > registered under the package name of the role itself. So when it > comes time to look up a method in the dispatch table, we're looking in > the wrong package name, and get this error: > > "did not match any known signature for multi sub" > > I'm not especially familiar with how Moo::Role works behind the > scenes, and so maybe this is unfixable, or undesired. But it seems > that if it were fixable, maybe Kavorka::Multi::__gather_candidates > would be the place to do it...? > > Do you have any thoughts on this? > > (Big fan of Kavorka - thank you!) > > Ryan Lang
Download (untitled) / with headers
text/plain 1.2k
Example in code: ------ package My::Role; use Moo::Role; use Types::Standard qw/ArrayRef HashRef/; use Kavorka qw/multi method/; multi method process (ArrayRef $x) { say "here" } multi method process (HashRef $x) { say "there" } package My::Consumer; use Moo; with 'My::Role'; __PACKAGE__->process( [] ); # blows up here: Arguments to My::Role::process did not match any known signature for multi sub __PACKAGE__->process( {} ); On Sat Dec 09 15:07:52 2017, RLANG wrote: Show quoted text
> Hi there- > > It appears that multi subs/methods don't work properly when being > composed in roles (Moo::Role). > > I did a little digging, and it seems that rather than methods being > registered under the package name of a role's consumer, they are > registered under the package name of the role itself. So when it > comes time to look up a method in the dispatch table, we're looking in > the wrong package name, and get this error: > > "did not match any known signature for multi sub" > > I'm not especially familiar with how Moo::Role works behind the > scenes, and so maybe this is unfixable, or undesired. But it seems > that if it were fixable, maybe Kavorka::Multi::__gather_candidates > would be the place to do it...? > > Do you have any thoughts on this? > > (Big fan of Kavorka - thank you!) > > Ryan Lang
Download (untitled) / with headers
text/plain 254b
To be honest, I've never really given the concept much thought, but multi methods in roles could be cool. Different roles might even define different signatures for the same method and the class could compose both. I do think this should be supported.


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.