=head1 DESCRIPTION
-The Moose cookbook is a series of recipies taken from the Moose
+The Moose cookbook is a series of recipes taken from the Moose
test suite. Each recipe presents some code, which demonstrates
some of the features of Moose, and then proceeds to explain the
details of the code.
=head1 NAME
-Moose::Cookbook::FAQ - Frequenty asked questions about Moose
+Moose::Cookbook::FAQ - Frequently asked questions about Moose
=head1 FREQUENTLY ASKED QUESTIONS
with, is B<very stable> and any changes B<will be 100% backwards
compatible>. The introspection API is I<mostly> stable, I still
reserve the right to tweak that if needed, but I will do my
-absolute best to maintain backwards comptability here as well.
+absolute best to maintain backwards compatibility here as well.
=head3 I heard Moose is slow, is this true?
Currently we have the option of making your classes immutable
as a means of boosting speed. This will mean a larger compile
time cost, but the runtime speed increase (especially in object
-construction) is pretty signifigant. This is not very well
+construction) is pretty significant. This is not very well
documented yet, so please ask on the list of on #moose for more
information.
We are also discussing and experimenting with L<Module::Compile>,
and the idea of compiling highly optimized C<.pmc> files. And
-we have also mapped out some core methods as canidates for
+we have also mapped out some core methods as candidates for
conversion to XS.
=head3 When will Moose be 1.0 ready?
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 initializtion code post instance construction,
+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 inheritence chain is called
+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.
+because it makes sub classing 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.
In short, try to use C<BUILD> and coercions, they are your best
bets.
-=head3 How do I make non-Moose constuctors work with Moose?
+=head3 How do I make non-Moose constructors work with Moose?
Moose provides it's own constructor, but it does it by making all
Moose-based classes inherit from L<Moose::Object>. When inheriting
-from a non-Moose class, the inheritence chain to L<Moose::Object>
+from a non-Moose class, the inheritance chain to L<Moose::Object>
is broken. The simplest way to fix this is to simply explicitly
inherit from L<Moose::Object> yourself. However, this does not
always fix the issue of a constructor. Here is a basic example of
package My::HTML::Template;
use Moose;
- # explict inheritence
+ # explicit inheritance
extends 'HTML::Template', 'Moose::Object';
# explicit constructor
Other techniques can be used as well, such as creating the object
using C<Moose::Object::new>, but calling the inherited non-Moose
-class's initializtion methods (if available).
+class's initialization methods (if available).
It is also entirely possible to just rely on HASH autovivification
to create the slot's needed for Moose based attributes. Although
is also outside the scope of this document, but I would be happy to
explain it on #moose or the mailing list.
-=head2 Method Modfiers
+=head2 Method Modifiers
=head3 How can I affect the values in C<@_> using C<before>?
Moose now handles turning C<strict> and C<warnings> on for you, so
all you need do is say C<use Moose>, and no kittens will die.
-By loading Moose, we are enabeling the Moose "environment" to be
+By loading Moose, we are enabling the Moose "environment" to be
loaded within our package. This means that we export some functions
which serve as Moose "keywords". This is nothing fancier than that,
just plain old exported functions.
that it is more explicit about defining the superclass relationship.
A small digression here, both Moose and C<extends> support multiple
-inheritence. You simply pass all the superclasses to C<extends>,
+inheritance. You simply pass all the superclasses to C<extends>,
like so:
extends 'Foo', 'Bar', 'Baz';
=head1 CONCLUSION
-I hope this recipe has given you some explaination of how to use
+I hope this recipe has given you some explanation of how to use
Moose to build you Perl 5 classes. The next recipe will build upon
the basics shown here with more complex attributes and methods.
Please read on :)
Future plans for Moose include allowing for alternate instance
structures such as blessed ARRAY refs and such. If you want you Moose
-classes to be interchangable, it is advised that you avoid direct
+classes to be interchangeable, it is advised that you avoid direct
instance access, like that which is shown above.
=back
=item Method Modifiers
The concept of method modifiers is directly ripped off from CLOS. A
-great explaination of them can be found by following this link.
+great explanation of them can be found by following this link.
L<http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html>
initialized to C<0>. Very simple really :)
Next come the methods. The C<deposit> and C<withdraw> methods
-should be fairly self explanitory, they are nothing specific to
+should be fairly self explanatory, they are nothing specific to
Moose, just your standard Perl 5 OO.
Now, onto the B<CheckingAccount> class. As you know from the
The aim of this recipe was to take the knowledge learned in the
first recipe and expand upon it within a more realistic use case.
I hope that this recipe has accomplished this goal. The next
-recipe will expand even more upon the capabilties of attributes
+recipe will expand even more upon the capabilities of attributes
in Moose to create a behaviorally sophisticated class almost
entirely defined by attributes.
=over 4
-=item Acknowledgement
+=item Acknowledgment
The BankAccount example in this recipe is directly taken from the
examples in this chapter of "Practical Common Lisp". A link to that
The class in this recipe is a classic binary tree, each node in the
tree is represented by an instance of the B<BinaryTree> class. Each
-instance has a C<node> slot to hold an abitrary value, a C<right>
+instance has a C<node> slot to hold an arbitrary value, a C<right>
slot to hold the right node, a C<left> slot to hold the left node,
and finally a C<parent> slot to hold a reference back up the tree.
has 'node' => (is => 'rw', isa => 'Any');
-If you recall from the previous recipies, this slot will have a
+If you recall from the previous recipes, this slot will have a
read/write accessor generated for it, and has a type constraint on it.
The new item here is the type constraint of C<Any>. In the type
-constraint heirarchy in L<Moose::Utils::TypeConstraints>, the C<Any>
+constraint hierarchy in L<Moose::Utils::TypeConstraints>, the C<Any>
constraint is the "root" of the hierarchy. It means exactly what it
says, it allows anything to pass. Now, you could just as easily have
left out the C<isa>, left the C<node> slot unconstrained and gotten the
state codes to be stored in the C<state> slot.
The next C<subtype>, does pretty much the same thing using the
-L<Regexp::Common> module, and constrainting the C<zip_code> slot.
+L<Regexp::Common> module, and constraining the C<zip_code> slot.
subtype USZipCode
=> as Value
});
Here, instead of passing a string to the C<isa> option, we are passing
-an anyonomous subtype of the C<ArrayRef> type constraint. This subtype
+an anonymous subtype of the C<ArrayRef> type constraint. This subtype
basically checks that all the values in the ARRAY ref are instance of
the B<Employee> class.
}
}
-The C<BUILD> method will have run after the intial type constraint
+The C<BUILD> method will have run after the initial type constraint
check, so we can do just a basic existence check on the C<employees>
param here, and assume that if it does exist, it is both an ARRAY ref
and full of I<only> instances of B<Employee>.
class and its subclass the previously mentioned B<Employee> class.
The B<Person> class should be obvious to you at this point. It has a few
-C<required> attributes, and the C<middle_intial> slot has an additional
+C<required> attributes, and the C<middle_initial> slot has an additional
C<predicate> method (which we saw in the previous recipe with the
B<BinaryTree> class).
Next the B<Employee> class, this too should be pretty obvious at this
-point. It requires a C<title>, and maintains a weakend reference to a
+point. It requires a C<title>, and maintains a weakened reference to a
B<Company> instance. The only new item, which we have seen before in
examples, but never in the recipe itself, is the C<override> method
modifier.
The C<BUILD> method is called by C<Moose::Object::BUILDALL>, which is
called by C<Moose::Object::new>. C<BUILDALL> will climb the object
-inheritence graph and call the approriate C<BUILD> methods in the
+inheritance graph and call the appropriate C<BUILD> methods in the
correct order.
=back
flexible and open API for your accessors, while still retaining
all the safety that comes from using Moose's type constraints.
Using coercions it becomes simple to manage (from a single
-location) a consisten API not only across multiple accessors,
+location) a consistent API not only across multiple accessors,
but across multiple classes as well.
In the next recipe, we will introduce roles, a concept originally
would overwrite your custom accessor. You wouldn't want that
would you?
-=head2 Method Modfiers
+=head2 Method Modifiers
=head3 How come I can't change C<@_> in a C<before> modifier?
projects / gitmo/Moose.git / commitdiff