combine to provide a powerful interface.
If you'd like to learn more about overloading, please read the
-documentation for the L<overload> pragme.
+documentation for the L<overload> pragma.
To see all the code we created together, take a look at
F<t/000_recipes/basics/010_genes.t>.
anything.
We could have left out the C<isa> option, but in this case, we are
-including ir for the benefit of other programmers, not the computer.
+including it for the benefit of other programmers, not the computer.
Next, let's move on to the C<parent> attribute:
In our case, we're making a new C<BinaryTree> object in our default,
with the current tree as the parent.
-Normally, when an object is instantiated, any defaults are evaluted
+Normally, when an object is instantiated, any defaults are evaluated
immediately. With our C<BinaryTree> class, this would be a big
problem! We'd create the first object, which would immediately try to
populate its C<left> and C<right> attributes, which would create a new
Finally, we introduce the C<required> attribute parameter.
The the C<Address> class we define two subtypes. The first uses the
-L<Locale::US> module to check the validaity of a state. It accepts
+L<Locale::US> module to check the validity of a state. It accepts
either a state abbreviation of full name.
A state will be passed in as a string, so we make our C<USState> type
This is just a sugary alternative to Perl's built in C<SUPER::>
feature. However, there is one difference. You cannot pass any
-arguments to C<super>. Instead, Moose ismply passes the same
+arguments to C<super>. Instead, Moose simply passes the same
parameters that were passed to the method.
A more detailed example of usage can be found in
To add a label to our attributes there are two steps. First, we need a
new attribute metaclass that can store a label for an
-attribute. Second, we nede to create attributes that use that
+attribute. Second, we need to create attributes that use that
attribute metaclass.
=head1 RECIPE REVIEW
sub register_implementation { 'MyApp::Meta::Attribute::Labeled' }
This is a bit of magic that lets us use a short name, "Labeled", when
-referring to our new metaclas.
+referring to our new metaclass.
That was the whole attribute metaclass.
label => "The site's URL",
);
-This looks like a normal attribute declaraion, except for two things,
+This looks like a normal attribute declaration, except for two things,
the C<metaclass> and C<label> parameters. The C<metaclass> parameter
tells Moose we want to use a custom metaclass for this (one)
attribute. The C<label> parameter will be stored in the meta-attribute
In L<Moose::Cookbook::Meta::Recipe2>, we created an attribute
metaclass which lets you provide a label for attributes.
-Using a metaclss works fine until you realize you want to add a label
+Using a metaclass works fine until you realize you want to add a label
I<and> an expiration, or some other combination of new behaviors. You
could create yet another metaclass which subclasses those two, but
that makes a mess, especially if you want to mix and match behaviors
=head1 DESCRIPTION
This recipe takes the metaclass table attribute from
-L<Moose::Cookbook::Meta::Recipe4> and mplements it as a metaclass
+L<Moose::Cookbook::Meta::Recipe4> and implements it as a metaclass
trait. Traits are just roles, as we saw in
L<Moose::Cookbook::Meta::Recipe3>.
reuse. This recipe demonstrates the latter, with roles that define
comparison and display code for objects.
-Let's start with CB<Eq>. First, note that we've replaced C<use Moose>
+Let's start with C<Eq>. First, note that we've replaced C<use Moose>
with C<use Moose::Role>. We also have a new sugar function, C<required>:
requires 'equal_to';
Overriding C<new> is a very bad practice. Instead, you should use a
C<BUILD> or C<BUILDARGS> methods to do the same thing. When you
override C<new>, Moose can no longer inline a constructor when your
-class is immutablized.
+class is immutabilized.
The only reason to override C<new> is if you are writing a MooseX
extension that provides its own L<Moose::Object> subclass I<and> a
Many of these practices also help get the most out of meta
programming. If you used an overridden C<new> to do type coercion by
hand, rather than defining a real coercion, there is no introspectable
-metadata. This sort of thing is particuarly problematic MooseX
+metadata. This sort of thing is particularly problematic MooseX
extensions which rely on introspection to do the right thing.
=head1 AUTHOR
composable
Debuggable
DEMOLISHALL
+hardcode
immutabilization
immutabilize
introspectable
Metaclass
METACLASS
metaclass's
+metadata
MetaObject
metaprogrammer
metarole
destructors
DWIM
hashrefs
+immutabilize
+immutabilized
inline
invocant
invocant's
projects / gitmo/Moose.git / commitdiff