[Moose-commits] r7639 - in Moose/trunk: lib/Moose/Cookbook/Basics
lib/Moose/Cookbook/Meta lib/Moose/Cookbook/Roles lib/Moose/Manual xt
autarch at code2.0beta.co.uk
autarch at code2.0beta.co.uk
Thu Feb 12 17:20:16 GMT 2009
Author: autarch
Date: 2009-02-12 09:20:16 -0800 (Thu, 12 Feb 2009)
New Revision: 7639
Modified:
Moose/trunk/lib/Moose/Cookbook/Basics/Recipe10.pod
Moose/trunk/lib/Moose/Cookbook/Basics/Recipe3.pod
Moose/trunk/lib/Moose/Cookbook/Basics/Recipe4.pod
Moose/trunk/lib/Moose/Cookbook/Meta/Recipe2.pod
Moose/trunk/lib/Moose/Cookbook/Meta/Recipe3.pod
Moose/trunk/lib/Moose/Cookbook/Meta/Recipe5.pod
Moose/trunk/lib/Moose/Cookbook/Roles/Recipe1.pod
Moose/trunk/lib/Moose/Manual/BestPractices.pod
Moose/trunk/xt/pod_spell.t
Log:
this speling test is really useful. fixed a whole bunch of types in the cookbook
Modified: Moose/trunk/lib/Moose/Cookbook/Basics/Recipe10.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Basics/Recipe10.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Basics/Recipe10.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -230,7 +230,7 @@
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>.
Modified: Moose/trunk/lib/Moose/Cookbook/Basics/Recipe3.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Basics/Recipe3.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Basics/Recipe3.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -59,7 +59,7 @@
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:
@@ -130,7 +130,7 @@
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
Modified: Moose/trunk/lib/Moose/Cookbook/Basics/Recipe4.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Basics/Recipe4.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Basics/Recipe4.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -107,7 +107,7 @@
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
@@ -245,7 +245,7 @@
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
Modified: Moose/trunk/lib/Moose/Cookbook/Meta/Recipe2.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Meta/Recipe2.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Meta/Recipe2.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -108,7 +108,7 @@
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
@@ -136,7 +136,7 @@
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.
@@ -157,7 +157,7 @@
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
Modified: Moose/trunk/lib/Moose/Cookbook/Meta/Recipe3.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Meta/Recipe3.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Meta/Recipe3.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -73,7 +73,7 @@
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
Modified: Moose/trunk/lib/Moose/Cookbook/Meta/Recipe5.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Meta/Recipe5.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Meta/Recipe5.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -26,7 +26,7 @@
=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>.
Modified: Moose/trunk/lib/Moose/Cookbook/Roles/Recipe1.pod
===================================================================
--- Moose/trunk/lib/Moose/Cookbook/Roles/Recipe1.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Cookbook/Roles/Recipe1.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -77,7 +77,7 @@
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';
Modified: Moose/trunk/lib/Moose/Manual/BestPractices.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/BestPractices.pod 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/lib/Moose/Manual/BestPractices.pod 2009-02-12 17:20:16 UTC (rev 7639)
@@ -40,7 +40,7 @@
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
@@ -204,7 +204,7 @@
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
Modified: Moose/trunk/xt/pod_spell.t
===================================================================
--- Moose/trunk/xt/pod_spell.t 2009-02-12 17:15:06 UTC (rev 7638)
+++ Moose/trunk/xt/pod_spell.t 2009-02-12 17:20:16 UTC (rev 7639)
@@ -74,6 +74,7 @@
composable
Debuggable
DEMOLISHALL
+hardcode
immutabilization
immutabilize
introspectable
@@ -81,6 +82,7 @@
Metaclass
METACLASS
metaclass's
+metadata
MetaObject
metaprogrammer
metarole
@@ -105,6 +107,8 @@
destructors
DWIM
hashrefs
+immutabilize
+immutabilized
inline
invocant
invocant's
More information about the Moose-commits
mailing list