Clarify that this wtf is about subroutine attributes
[gitmo/Moose.git] / lib / Moose / Cookbook / WTF.pod
CommitLineData
e67a0fca 1
2=pod
3
4=head1 NAME
5
6Moose::Cookbook::WTF - For when things go wrong with Moose
7
8=head1 COMMON PROBLEMS
9
2a0f3bd3 10=head2 Speed
11
12=head3 Why is my code taking so long to load?
13
d44714be 14Moose does have a compile time performance burden,
15which it inherits from Class::MOP. If load/compile
16time is a concern for your application, Moose may not
17be the right tool for you.
2a0f3bd3 18
19Although, you should note that we are exploring the
20use of L<Module::Compile> to try and reduce this problem,
21but nothing is ready yet.
22
23=head3 Why are my objects taking so long to construct?
24
25Moose uses a lot of introspection when constructing an
734d1752 26instance, and introspection can be slow. This problem
27can be solved by making your class immutable. This can
28be done with the following code:
2a0f3bd3 29
734d1752 30 MyClass->meta->make_immutable();
31
32Moose will then memoize a number of meta-level methods
33and inline a constructor for you. For more information
34on this see the L<Constructors> section below and in the
35L<Moose::Cookbook::FAQ>.
36
37=head2 Constructors & Immutability
38
39=head3 I made my class immutable, but C<new> it is still slow!
40
41Do you have a custom C<new> method in your class? Moose
42will not overwrite your custom C<new> method, you would
43probably do better to try and convert this to use the
44C<BUILD> method or possibly set C<default> values in
45the attribute declaration.
46
d44714be 47=head3 I made my class immutable, and now my (before | after |
48 around) C<new> is not being called?
734d1752 49
50Making a I<before>, I<after> or I<around> wrap around the
51C<new> method, will actually create a C<new> method within
52your class. This will prevent Moose from creating one itself
53when you make the class immutable.
e67a0fca 54
55=head2 Accessors
56
57=head3 I created an attribute, where are my accessors?
58
59Accessors are B<not> created implicitly, you B<must> ask Moose
60to create them for you. My guess is that you have this:
61
62 has 'foo' => (isa => 'Bar');
63
64when what you really want to say is:
65
66 has 'foo' => (isa => 'Bar', is => 'rw');
67
68The reason this is so, is because it is a perfectly valid use
69case to I<not> have an accessor. The simplest one is that you
70want to write your own. If Moose created on automatically, then
71because of the order in which classes are constructed, Moose
72would overwrite your custom accessor. You wouldn't want that
73would you?
74
4711f5f7 75=head2 Method Modifiers
e67a0fca 76
77=head3 How come I can't change C<@_> in a C<before> modifier?
78
79The C<before> modifier simply is called I<before> the main method.
80Its return values are simply ignored, and are B<not> passed onto
81the main method body.
82
83There are a number of reasons for this, but those arguments are
84too lengthy for this document. Instead, I suggest using an C<around>
85modifier instead. Here is some sample code:
86
87 around 'foo' => sub {
88 my $next = shift;
89 my ($self, @args) = @_;
90 # do something silly here to @args
91 $next->($self, reverse(@args));
92 };
93
94=head3 How come I can't see return values in an C<after> modifier?
95
96As with the C<before> modifier, the C<after> modifier is simply
97called I<after> the main method. It is passed the original contents
98of C<@_> and B<not> the return values of the main method.
99
100Again, the arguments are too lengthy as to why this has to be. And
101as with C<before> I recommend using an C<around> modifier instead.
102Here is some sample code:
103
104 around 'foo' => sub {
105 my $next = shift;
106 my ($self, @args) = @_;
107 my @rv = $next->($self, @args);
108 # do something silly with the return values
109 return reverse @rv;
110 };
111
01cee734 112=head2 Moose and Subroutine Attributes
43b50af3 113
01cee734 114=head3 Why don't subroutine attributes I inherited from a superclass work?
43b50af3 115
116Currently when you subclass a module, this is done at runtime with
117the C<extends> keyword but attributes are checked at compile time
118by Perl. To make attributes work, you must place C<extends> in a
119C<BEGIN> block so that the attribute handlers will be available at
120compile time like this:
121
01cee734 122 BEGIN { extends qw/Foo/ }
123
124Note that we're talking about Perl's subroutine attributes here, not
125Moose attributes:
126
127 sub foo : Bar(27) { ... }
43b50af3 128
129=head2 Moose and Other Modules
130
131=head3 Why can't I get Catalyst and Moose to work together?
132
133See L<Moose and Attributes>.
134
b36c8076 135=head2 Roles
136
137=head3 How come BUILD is not called for my composed roles?
138
139BUILD is never called in composed roles. The primary reason is that
140roles are B<not> order sensitive. Roles are composed in such a way
141that the order of composition does not matter (for information on
142the deeper theory of this read the original traits papers here
143L<http://www.iam.unibe.ch/~scg/Research/Traits/>).
144
6549b0d1 145Because roles are essentially unordered, it would be impossible to
b36c8076 146determine the order in which to execute the BUILD methods.
147
148As for alternate solutions, there are a couple.
149
150=over 4
151
152=item *
153
154Using a combination of lazy and default in your attributes to
155defer initialization (see the Binary Tree example in the cookbook
156for a good example of lazy/default usage
a3fd32fb 157L<Moose::Cookbook::Basics::Recipe3>)
b36c8076 158
159=item *
160
6549b0d1 161Use attributes triggers, which fire after an attribute it set, to facilitate
b36c8076 162initialization. These are described in the L<Moose> docs and examples can be
163found in the test suite.
164
165=back
166
6549b0d1 167In general, roles should not I<require> initialization, they should either
b36c8076 168provide sane defaults or should be documented as needing specific
6549b0d1 169initialization. One such way to "document" this is to have a separate
b36c8076 170attribute initializer which is required for the role. Here is an example of
171how to do this:
172
173 package My::Role;
174 use Moose::Role;
175
176 has 'height' => (
177 is => 'rw',
178 isa => 'Int',
179 lazy => 1,
180 default => sub {
181 my $self = shift;
182 $self->init_height;
183 }
184 );
185
186 requires 'init_height';
187
188In this example, the role will not compose successfully unless the class
189provides a C<init_height> method.
190
191If none of those solutions work, then it is possible that a role is not
192the best tool for the job, and you really should be using classes. Or, at
193the very least, you should reduce the amount of functionality in your role
194so that it does not require initialization.
195
e67a0fca 196=head1 AUTHOR
197
198Stevan Little E<lt>stevan@iinteractive.comE<gt>
199
43b50af3 200Anders Nor Berle E<lt>debolaz@gmail.comE<gt>
201
e67a0fca 202=head1 COPYRIGHT AND LICENSE
203
2840a3b2 204Copyright 2006-2009 by Infinity Interactive, Inc.
e67a0fca 205
206L<http://www.iinteractive.com>
207
208This library is free software; you can redistribute it and/or modify
209it under the same terms as Perl itself.
210
43b50af3 211=cut