+++ /dev/null
-
-=pod
-
-=head1 NAME
-
-Moose::Cookbook::WTF - For when things go wrong with Moose
-
-=head1 COMMON PROBLEMS
-
-=head2 Speed
-
-=head3 Why is my code taking so long to load?
-
-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 L<Module::Compile> to try and reduce this problem,
-but nothing is ready yet.
-
-=head3 Why are my objects taking so long to construct?
-
-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 L<Constructors> section below and in the
-L<Moose::Cookbook::FAQ>.
-
-=head2 Constructors & Immutability
-
-=head3 I made my class immutable, but C<new> is still slow!
-
-Do you have a custom C<new> method in your class? Moose
-will not overwrite your custom C<new> method, you would
-probably do better to try and convert this to use the
-C<BUILD> method or possibly set C<default> values in
-the attribute declaration.
-
-=head3 I made my class immutable, and now my (before | after |
- around) C<new> is not being called?
-
-Making a I<before>, I<after> or I<around> wrap around the
-C<new> method will actually create a C<new> method within
-your class. This will prevent Moose from creating one itself
-when you make the class immutable.
-
-=head2 Accessors
-
-=head3 I created an attribute, where are my accessors?
-
-Accessors are B<not> created implicitly, you B<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 I<not> have an accessor. The simplest one is that you
-want to write your own. If Moose created one automatically, then
-because of the order in which classes are constructed, Moose
-would overwrite your custom accessor. You wouldn't want that
-would you?
-
-=head2 Method Modifiers
-
-=head3 Why can't I change C<@_> in a C<before> modifier?
-
-The C<before> modifier is called I<before> the main method.
-Its return values are simply ignored, and are B<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 C<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));
- };
-
-=head3 Why can't I see return values in an C<after> modifier?
-
-As with the C<before> modifier, the C<after> modifier is simply
-called I<after> the main method. It is passed the original contents
-of C<@_> and B<not> the return values of the main method.
-
-Again, the arguments are too lengthy as to why this has to be. And
-as with C<before> I recommend using an C<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;
- };
-
-=head2 Moose and Subroutine Attributes
-
-=head3 Why don't subroutine attributes I inherited from a superclass work?
-
-Currently when you subclass a module, this is done at runtime with
-the C<extends> keyword but attributes are checked at compile time
-by Perl. To make attributes work, you must place C<extends> in a
-C<BEGIN> block so that the attribute handlers will be available at
-compile time like this:
-
- BEGIN { extends qw/Foo/ }
-
-Note that we're talking about Perl's subroutine attributes here, not
-Moose attributes:
-
- sub foo : Bar(27) { ... }
-
-=head2 Moose and Other Modules
-
-=head3 Why can't I get Catalyst and Moose to work together?
-
-See L<Moose and Attributes>.
-
-=head2 Roles
-
-=head3 Why is BUILD not called for my composed roles?
-
-BUILD is never called in composed roles. The primary reason is that
-roles are B<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
-L<http://www.iam.unibe.ch/~scg/Research/Traits/>).
-
-Because roles are essentially unordered, it would be impossible to
-determine the order in which to execute the BUILD methods.
-
-As for alternate solutions, there are a couple.
-
-=over 4
-
-=item *
-
-Using a combination of lazy and default in your attributes to
-defer initialization (see the Binary Tree example in the cookbook
-for a good example of lazy/default usage
-L<Moose::Cookbook::Basics::Recipe3>)
-
-=item *
-
-Use attribute triggers, which fire after an attribute is set, to facilitate
-initialization. These are described in the L<Moose> docs, and examples can be
-found in the test suite.
-
-=back
-
-In general, roles should not I<require> initialization; they should either
-provide sane defaults or should be documented as needing specific
-initialization. One such way to "document" this is to have a separate
-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 C<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.
-
-=head1 AUTHOR
-
-Stevan Little E<lt>stevan@iinteractive.comE<gt>
-
-Anders Nor Berle E<lt>debolaz@gmail.comE<gt>
-
-=head1 COPYRIGHT AND LICENSE
-
-Copyright 2006-2009 by Infinity Interactive, Inc.
-
-L<http://www.iinteractive.com>
-
-This library is free software; you can redistribute it and/or modify
-it under the same terms as Perl itself.
-
-=cut
=head1 NAME
-Moose::Cookbook::FAQ - Frequently asked questions about Moose
+Moose::Manual::FAQ - Frequently asked questions about Moose
=head1 FREQUENTLY ASKED QUESTIONS
=head3 Is Moose "production ready"?
Yes! Many sites with household names are using Moose to build
-high-traffic services. Countless others are using Moose in
-production.
+high-traffic services. Countless others are using Moose in production.
As of this writing, Moose is a dependency of several hundred CPAN
modules. L<http://cpants.perl.org/dist/used_by/Moose>
Again, this one is tricky, so Yes I<and> No.
-Firstly, I<nothing> in life is free, and some Moose features
-do cost more than others. It is also the policy of Moose to
-B<only charge you for the features you use>, and to do our
-absolute best to not place any extra burdens on the execution
-of your code for features you are not using. Of course using
-Moose itself does involve some overhead, but it is mostly
-compile time. At this point we do have some options available
-for getting the speed you need.
+Firstly, I<nothing> in life is free, and some Moose features do cost
+more than others. It is also the policy of Moose to B<only charge you
+for the features you use>, and to do our absolute best to not place
+any extra burdens on the execution of your code for features you are
+not using. Of course using Moose itself does involve some overhead,
+but it is mostly compile time. At this point we do have some options
+available for getting the speed you need.
-Currently we provide the option of making your classes immutable
-as a means of boosting speed. This will mean a slightly larger compile
-time cost, but the runtime speed increase (especially in object
-construction) is pretty significant.
+Currently we provide the option of making your classes immutable as a
+means of boosting speed. This will mean a slightly larger compile time
+cost, but the runtime speed increase (especially in object
+construction) is pretty significant. This can be done with the
+following code:
+
+ MyClass->meta->make_immutable();
We are regularly converting the hotspots of L<Class::MOP> to XS.
-Florian Ragwitz and Yuval Kogman are currently working on a way
-to compile your accessors and instances directly into C, so that
-everyone can enjoy blazing fast OO.
+Florian Ragwitz and Yuval Kogman are currently working on a way to
+compile your accessors and instances directly into C, so that everyone
+can enjoy blazing fast OO.
=head3 When will Moose 1.0 be ready?
-Moose is ready now! Stevan Little declared 0.18, released in March 2007,
-to be "ready to use".
+Moose is ready now! Stevan Little declared 0.18, released in March
+2007, to be "ready to use".
=head2 Constructors
=head3 How do I write custom constructors with Moose?
-Ideally, you should never write your own C<new> method, and should
-use Moose's other features to handle your specific object construction
+Ideally, you should never write your own C<new> method, and should use
+Moose's other features to handle your specific object construction
needs. Here are a few scenarios, and the Moose way to solve them;
If you need to call initialization code post instance construction,
-then use the C<BUILD> method. This feature is taken directly from
-Perl 6. Every C<BUILD> method in your inheritance chain is called
-(in the correct order) immediately after the instance is constructed.
-This allows you to ensure that all your superclasses are initialized
+then use the C<BUILD> method. This feature is taken directly from Perl
+6. Every C<BUILD> method in your inheritance chain is called (in the
+correct order) immediately after the instance is constructed. This
+allows you to ensure that all your superclasses are initialized
properly as well. This is the best approach to take (when possible)
because it makes subclassing your class much easier.
If you need to affect the constructor's parameters prior to the
instance actually being constructed, you have a number of options.
-To change the parameter processing as a whole, you can use
-the C<BUILDARGS> method. The default implementation accepts key/value
-pairs or a hash reference. You can override it to take positional args,
-or any other format
+To change the parameter processing as a whole, you can use the
+C<BUILDARGS> method. The default implementation accepts key/value
+pairs or a hash reference. You can override it to take positional
+args, or any other format
-To change the handling of individual parameters, there are I<coercions>
-(See the L<Moose::Cookbook::Basics::Recipe5> for a complete example and
-explanation of coercions). With coercions it is possible to morph
-argument values into the correct expected types. This approach is the
-most flexible and robust, but does have a slightly higher learning
-curve.
+To change the handling of individual parameters, there are
+I<coercions> (See the L<Moose::Cookbook::Basics::Recipe5> for a
+complete example and explanation of coercions). With coercions it is
+possible to morph argument values into the correct expected
+types. This approach is the most flexible and robust, but does have a
+slightly higher learning curve.
=head3 How do I make non-Moose constructors work with Moose?
Usually the correct approach to subclassing a non-Moose class is
delegation. Moose makes this easy using the C<handles> keyword,
-coercions, and C<lazy_build>, so subclassing is often not the
-ideal route.
+coercions, and C<lazy_build>, so subclassing is often not the ideal
+route.
That said, if you really need to inherit from a non-Moose class, see
-L<Moose::Cookbook::Basics::Recipe12> for an example of how to do it.
+L<Moose::Cookbook::Basics::Recipe12> for an example of how to do it,
+or take a look at L<MooseX::NonMoose> on CPAN.
=head2 Accessors
Moose will still take advantage of type constraints, triggers, etc.
when creating these methods.
-If you do not like this much typing, and wish it to be a default for your
-classes, please see L<MooseX::FollowPBP>. This extension will allow you to
-write:
+If you do not like this much typing, and wish it to be a default for
+your classes, please see L<MooseX::FollowPBP>. This extension will
+allow you to write:
has 'bar' => (
isa => 'Baz',
is => 'rw',
);
-Moose will create separate C<get_bar> and C<set_bar> methods
-instead of a single C<bar> method.
+Moose will create separate C<get_bar> and C<set_bar> methods instead
+of a single C<bar> method.
+
+If you like C<bar> and C<set_bar>, see
+L<MooseX::SemiAffordanceAccessor>.
NOTE: This B<cannot> be set globally in Moose, as that would break
other classes which are built with Moose. You can still save on typing
by defining a new L<MyApp::Moose> that exports Moose's sugar and then
-turns on L<MooseX::FollowPBP>. See L<Moose::Cookbook::Extending::Recipe4>.
+turns on L<MooseX::FollowPBP>. See
+L<Moose::Cookbook::Extending::Recipe4>.
=head3 How can I inflate/deflate values in accessors?
For a more comprehensive example of using coercions, see the
L<Moose::Cookbook::Basics::Recipe5>.
-If you need to deflate your attribute's value, the current best practice
-is to add an C<around> modifier to your accessor:
+If you need to deflate your attribute's value, the current best
+practice is to add an C<around> modifier to your accessor:
# a timestamp which stores as
# seconds from the epoch
return $self->$next( $timestamp->epoch );
};
-It is also possible to do deflation using coercion, but this tends
-to get quite complex and require many subtypes. An example of this
-is outside the scope of this document, ask on #moose or send a mail
-to the list.
+It is also possible to do deflation using coercion, but this tends to
+get quite complex and require many subtypes. An example of this is
+outside the scope of this document, ask on #moose or send a mail to
+the list.
Still another option is to write a custom attribute metaclass, which
is also outside the scope of this document, but we would be happy to
explain it on #moose or the mailing list.
+=head3 I created an attribute, where are my accessors?
+
+Accessors are B<not> created implicitly, you B<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
+I<not> have an accessor. The simplest one is that you want to write
+your own. If Moose created one automatically, then because of the
+order in which classes are constructed, Moose would overwrite your
+custom accessor. You wouldn't want that would you?
+
=head2 Method Modifiers
=head3 How can I affect the values in C<@_> using C<before>?
-You can't, actually: C<before> only runs before the main method,
-and it cannot easily affect the method's execution.
+You can't, actually: C<before> only runs before the main method, and
+it cannot easily affect the method's execution.
You similarly can't use C<after> to affect the return value of a
method.
original method, or forwarding its return value (being careful to
preserve context).
-The C<around> method modifier has neither of these limitations, but
-is a little more verbose.
+The C<around> method modifier has neither of these limitations, but is
+a little more verbose.
=head3 Can I use C<before> to stop execution of a method?
By choosing not to call the C<$next> method, you can stop the
execution of the main method.
+=head3 Why can't I see return values in an C<after> modifier?
+
+As with the C<before> modifier, the C<after> modifier is simply called
+I<after> the main method. It is passed the original contents of C<@_>
+and B<not> the return values of the main method.
+
+Again, the arguments are too lengthy as to why this has to be. And as
+with C<before> I recommend using an C<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;
+ };
+
=head2 Type Constraints
=head3 How can I provide a custom error message for a type constraint?
=head3 Can I turn off type constraint checking?
-Not yet. This option will likely come in a future release.
+Not yet. This option may come in a future release.
=head2 Roles
-=head3 How do I get Moose to call BUILD in all my composed roles?
+=head3 Why is BUILD not called for my composed roles?
+
+BUILD is never called in composed roles. The primary reason is that
+roles are B<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
+L<http://www.iam.unibe.ch/~scg/Research/Traits/>).
+
+Because roles are essentially unordered, it would be impossible to
+determine the order in which to execute the BUILD methods.
+
+As for alternate solutions, there are a couple.
+
+=over 4
-See L<Moose::Cookbook::WTF> and specifically the
-B<Why is BUILD not called for my composed roles?> question in the
-B<Roles> section.
+=item *
+
+Using a combination of lazy and default in your attributes to defer
+initialization (see the Binary Tree example in the cookbook for a good
+example of lazy/default usage L<Moose::Cookbook::Basics::Recipe3>)
+
+=item *
+
+Use attribute triggers, which fire after an attribute is set, to
+facilitate initialization. These are described in the L<Moose> docs,
+and examples can be found in the test suite.
+
+=back
+
+In general, roles should not I<require> initialization; they should
+either provide sane defaults or should be documented as needing
+specific initialization. One such way to "document" this is to have a
+separate 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 C<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.
=head3 What are Traits, and how are they different from Roles?
In Moose-speak, a I<Role> is usually composed into a I<class> at
compile time, whereas a I<Trait> is usually composed into an instance
-of a class at runtime to add or modify the behavior of
-B<just that instance>.
+of a class at runtime to add or modify the behavior of B<just that
+instance>.
+
+Outside the context of Moose, traits and roles generally mean exactly
+the same thing. The original paper called them Traits, however Perl 6
+will call them Roles.
+
+=head2 Moose and Subroutine Attributes
+
+=head3 Why don't subroutine attributes I inherited from a superclass work?
+
+Currently when you subclass a module, this is done at runtime with the
+C<extends> keyword but attributes are checked at compile time by
+Perl. To make attributes work, you must place C<extends> in a C<BEGIN>
+block so that the attribute handlers will be available at compile time
+like this:
+
+ BEGIN { extends qw/Foo/ }
+
+Note that we're talking about Perl's subroutine attributes here, not
+Moose attributes:
-Outside the context of Moose, traits and roles generally mean exactly the
-same thing. The original paper called them Traits, however Perl 6 will call
-them Roles.
+ sub foo : Bar(27) { ... }
=head1 AUTHOR
projects / gitmo/Moose.git / commitdiff