Bug #123849 for Kavorka: Unable to use Multi Methods in Roles

Sat Dec 09 15:07:52 2017 RLANG [...] cpan.org - Ticket created

Subject:

Unable to use Multi Methods in Roles

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

Sat Dec 09 15:14:33 2017 RLANG [...] cpan.org - Correspondence added

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

Sat Dec 09 15:14:33 2017 RLANG [...] cpan.org - Correspondence added

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

Tue Jun 26 06:01:15 2018 perl [...] toby.ink - Correspondence added

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.

Tue Jun 26 06:01:16 2018 The RT System itself - Status changed from 'new' to 'open'