Fitz,

I am not sure when that behavior will change so a TODO test is probably still very premature.

I think docs would be better placed in Moose where we discuss the alias and exclude features of roles. Patches are always welcome.

- Stevan

On May 31, 2009, at 2:02 PM, Fitz Elliott wrote:

Hello All,

I have a Role that uses MooseX::AttributeHelpers to provide convenience methods for its attributes. I ran into a problem when I tried to alias the provided methods in the composing class. Here is the example code:

 package DoesFetch;
 use Moose::Role;
 use MooseX::AttributeHelpers;
 has 'queued' => (
                  metaclass => 'Collection::Array',
                  is        => 'ro',
                  isa       => 'ArrayRef[Int]',
                  default   => sub { [] },
                  provides  => {push => 'add_ids'},
                 );

 package Source::Pubmed;
 use Moose;
 with 'DoesFetch' => {alias => {add_ids => 'add_pmids',}};

 package main;
 my $source = Source::Pubmed->new();
 $source->add_ids(1..10);     # works
 $source->add_pmids(11..20);  # dies: Can't locate object method
# "add_pmids" via package "Source::Pubmed"

I've worked around this by adding a wrapper sub to Source::Pubmed, but I was curious as to why this didn't work. After doing some debugging, I found that 'add_ids' was being installed in Source::Pubmed's namespace, but not DoesFetch's. The aliasing code in Moose::Meta::Role::Application::ToClass gets the methods from the Role and DoesFetch doesn't know that 'add_ids' is one of its methods.

In the perldoc for Moose::Meta::Role, under "Attributes", it says:

"However, attributes stored in this class are not stored as objects. Rather, the attribute definition is stored as a hash reference. When a role is composed into a class, this hash reference is passed directly to the metaclass's add_attribute method."

 "This is quite likely to change in the future."
(http://search.cpan.org/~drolsky/Moose-0.79/lib/Moose/Meta/Role.pm#Attributes )

I'm assuming from this that MX::AttributeHelpers runs when the attributes are inflated, and therefore can't install its methods into the Role. Is that correct? Would it be helpful if I were to provide a note for the MX::AttributeHelpers docs that warns about this usage? I can also provide a TODO test, if this behavior is still expected to change.

Thanks everyone, for such a fantastic module!

Cheers,
Fitz




Reply via email to