Bug #42374 for MooseX-Method-Signatures: Role's 'requires' doesn't recognize methods

Tue Jan 13 12:08:02 2009 yanick+cpan [...] babyl.dyndns.org - Ticket created

Subject:

Role's 'requires' doesn't recognize methods

Between the black voodoo of M:M:S and the arcane meta-magic of Roles, it seems that methods aren't recognized by Roles: yanick@enkidu ~/tmp $ cat Foo.pm package Foo; use Moose; use strict; use warnings; use MooseX::Method::Signatures; with 'Bar'; method frobuscate { } 1; yanick@enkidu ~/tmp $ cat Bar.pm package Bar; use strict; use warnings; use Moose::Role; requires 'frobuscate'; 1; yanick@enkidu ~/tmp $ perl Foo.pm 'Bar' requires the method 'frobuscate' to be implemented by 'Foo' at /usr/local/lib/perl5/site_perl/5.10.0/Moose/Meta/Role/Application.pm line 59 Moose::Meta::Role::Application::apply('Moose::Meta::Role::Application::ToClass=HASH(0x8a50448)', 'Moose::Meta::Role=HASH(0x8a507a8)', 'Moose::Meta::Class=HASH(0x8586598)') called at /usr/local/lib/perl5/site_perl/5.10.0/Moose/Meta/Role/Application/ToClass.pm line 17 Moose::Meta::Role::Application::ToClass::apply('Moose::Meta::Role::Application::ToClass=HASH(0x8a50448)', 'Moose::Meta::Role=HASH(0x8a507a8)', 'Moose::Meta::Class=HASH(0x8586598)') called at /usr/local/lib/perl5/site_perl/5.10.0/Moose/Meta/Role.pm line 447 Moose::Meta::Role::apply('Moose::Meta::Role=HASH(0x8a507a8)', 'Moose::Meta::Class=HASH(0x8586598)') called at /usr/local/lib/perl5/site_perl/5.10.0/Moose/Util.pm line 93 Moose::Util::apply_all_roles('Moose::Meta::Class=HASH(0x8586598)', 'Bar') called at /usr/local/lib/perl5/site_perl/5.10.0/Moose.pm line 70 Moose::with('Foo', 'Bar') called at /usr/local/lib/perl5/site_perl/5.10.0/Moose/Exporter.pm line 186 Moose::with('Bar') called at Foo.pm line 10

Tue Jan 13 12:35:36 2009 rafl [...] debian.org - Correspondence added

Subject:	Re: [rt.cpan.org #42374] Role's 'requires' doesn't recognize methods
Date:	Tue, 13 Jan 2009 18:33:57 +0100
To:	Yanick Champoux via RT <bug-MooseX-Method-Signatures [...] rt.cpan.org>
From:	Florian Ragwitz <rafl [...] debian.org>

Hi, thanks for your report! On Tue, Jan 13, 2009 at 12:08:08PM -0500, Yanick Champoux via RT wrote: Show quoted text

> Between the black voodoo of M:M:S and the arcane meta-magic of Roles, it > seems that methods aren't recognized by Roles:

The method keyword, unlike 'sub', happens at runtime. So does the 'with' keyword Moose provides. In the example you provide you apply a role requiring a method before that method is declared. You can work that around by moving the role application past the method declaration. Another solution would be to use MooseX::Declare instead of plain MooseX::Method::Signatures. It defers application of roles until the end of the class definition. With it, your example would look like this: $ cat Foo.pm use MooseX::Declare; class Foo with Bar { method frobuscate { } } 1; $ cat Bar.pm use MooseX::Declare; role Bar { requires 'frobuscate'; } 1; I'm afraid there's not much MX::M::S could do about that other than clearly documenting this common pitfall. Maybe you feel like providing a documentation patch: the git repository is at git://github.com/rafl/moosex-method-signatures.git -- BOFH excuse #273: The cord jumped over and hit the power switch.

Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

Tue Jan 13 12:35:37 2009 The RT System itself - Status changed from 'new' to 'open'

Tue Jan 13 12:54:32 2009 yanick [...] babyl.dyndns.org - Correspondence added

Subject:	Re: [rt.cpan.org #42374] Role's 'requires' doesn't recognize methods
Date:	Tue, 13 Jan 2009 13:49:17 -0500
To:	Florian Ragwitz via RT <bug-MooseX-Method-Signatures [...] rt.cpan.org>
From:	yanick [...] babyl.dyndns.org

Hi! On Tue, Jan 13, 2009 at 12:35:39PM -0500, Florian Ragwitz via RT wrote: Show quoted text

> thanks for your report!

My pleasure. :-) Show quoted text

> On Tue, Jan 13, 2009 at 12:08:08PM -0500, Yanick Champoux via RT wrote:

> > Between the black voodoo of M:M:S and the arcane meta-magic of Roles, it > > seems that methods aren't recognized by Roles:

> > The method keyword, unlike 'sub', happens at runtime. So does the 'with' > keyword Moose provides.

Yeah, I was pretty sure it'd be something like that. I didn't try to pinpoint the problem exactly because I'm not yet fully familiar with Moose's meta-juggling, and the magic you guys are pulling with M::M::S just plain terrify me (in a good, awe-inspiring way). :-) Show quoted text

> In the example you provide you apply a role requiring a method before > that method is declared. You can work that around by moving the role > application past the method declaration.

Ach so... I see! Show quoted text

> Another solution would be to use MooseX::Declare instead of plain > MooseX::Method::Signatures. It defers application of roles until the end > of the class definition. With it, your example would look like this: > > $ cat Foo.pm > use MooseX::Declare; > > class Foo with Bar { > method frobuscate { } > } > > 1; > > $ cat Bar.pm > use MooseX::Declare; > > role Bar { > requires 'frobuscate'; > } > > 1;

I think I like that. It's infinitely better than sticking the 'with' way down past the method declarations. Heh. I guess that is proves that syntaxic sugar is like violence: if it doesn't solve your problem, it's simply because you are not using enough of it. :-) Show quoted text

> I'm afraid there's not much MX::M::S could do about that other than > clearly documenting this common pitfall. Maybe you feel like providing a > documentation patch: the git repository is at > git://github.com/rafl/moosex-method-signatures.git

Funnily enough, I found the repository a few minutes ago and put it on my watch list. I'll try to come up with a doc patch (which will probably end up being "heavily inspired" -- read here: almost taken verbatim -- from your answer). It should pop up on github sometime later this week. Many thanks for the quick'n'thorough answer (not to mention for M:M:S itself)! Joy, `/anick --

Sat Feb 21 14:17:28 2009 rafl [...] debian.org - Correspondence added

Closing this ticket as the documentation addresses the issue now.

Sat Feb 21 14:17:38 2009 rafl [...] debian.org - Status changed from 'open' to 'resolved'