| Moose::Cookbook::WTF - For when things go wrong with Moose |
new it is still slow!@_ in a before modifier?after modifier?
Moose::Cookbook::WTF - For when things go wrong with Moose
Moose does have a compile time performance burden, which it inherits from Class::MOP. If load/compile time is a concern for your application, Moose may not be the right tool for you.
Although, you should note that we are exploring the use of the Module::Compile manpage to try and reduce this problem, but nothing is ready yet.
Moose uses a lot of introspection when constructing an instance, and introspection can be slow. This problem can be solved by making your class immutable. This can be done with the following code:
MyClass->meta->make_immutable();
Moose will then memoize a number of meta-level methods and inline a constructor for you. For more information on this see the Constructors section below and in the the Moose::Cookbook::FAQ manpage.
new it is still slow!Do you have a custom new method in your class? Moose
will not overwrite your custom new method, you would
probably do better to try and convert this to use the
BUILD method or possibly set default values in
the attribute declaration.
new is not being called?Making a before, after or around wrap around the
new method, will actually create a new method within
your class. This will prevent Moose from creating one itself
when you make the class immutable.
Accessors are not created implicitly, you must ask Moose to create them for you. My guess is that you have this:
has 'foo' => (isa => 'Bar');
when what you really want to say is:
has 'foo' => (isa => 'Bar', is => 'rw');
The reason this is so, is because it is a perfectly valid use case to not have an accessor. The simplest one is that you want to write your own. If Moose created on automatically, then because of the order in which classes are constructed, Moose would overwrite your custom accessor. You wouldn't want that would you?
@_ in a before modifier?The before modifier simply is called before the main method.
Its return values are simply ignored, and are not passed onto
the main method body.
There are a number of reasons for this, but those arguments are
too lengthy for this document. Instead, I suggest using an around
modifier instead. Here is some sample code:
around 'foo' => sub {
my $next = shift;
my ($self, @args) = @_;
# do something silly here to @args
$next->($self, reverse(@args));
};
after modifier?As with the before modifier, the after modifier is simply
called after the main method. It is passed the original contents
of @_ and not the return values of the main method.
Again, the arguments are too lengthy as to why this has to be. And
as with before I recommend using an around modifier instead.
Here is some sample code:
around 'foo' => sub {
my $next = shift;
my ($self, @args) = @_;
my @rv = $next->($self, @args);
# do something silly with the return values
return reverse @rv;
};
Currently when you subclass a module, this is done at runtime with
the extends keyword but attributes are checked at compile time
by Perl. To make attributes work, you must place extends in a
BEGIN block so that the attribute handlers will be available at
compile time like this:
BEGIN { extends qw/Foo/ }
See Moose and Attributes.
BUILD is never called in composed roles. The primary reason is that roles are not order sensitive. Roles are composed in such a way that the order of composition does not matter (for information on the deeper theory of this read the original traits papers here http://www.iam.unibe.ch/~scg/Research/Traits/).
Because roles are essentially un-ordered, it would be impossible to determine the order in which to execute the BUILD methods.
As for alternate solutions, there are a couple.
In general, roles should not require intialization, they should either provide sane defaults or should be documented as needing specific initialization. One such way to ``document'' this is to have a seperate attribute initializer which is required for the role. Here is an example of how to do this:
package My::Role;
use Moose::Role;
has 'height' => (
is => 'rw',
isa => 'Int',
lazy => 1,
default => sub {
my $self = shift;
$self->init_height;
}
);
requires 'init_height';
In this example, the role will not compose successfully unless the class
provides a init_height method.
If none of those solutions work, then it is possible that a role is not the best tool for the job, and you really should be using classes. Or, at the very least, you should reduce the amount of functionality in your role so that it does not require initialization.
Stevan Little <stevan@iinteractive.com>
Anders Nor Berle <debolaz@gmail.com>
Copyright 2006-2008 by Infinity Interactive, Inc.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
| Moose::Cookbook::WTF - For when things go wrong with Moose |