From: Dave Rolsky <autarch@urth.org>
Date: Thu, 12 Feb 2009 17:20:16 +0000 (+0000)
Subject: this speling test is really useful. fixed a whole bunch of types in the cookbook
X-Git-Tag: 0.69~3
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=19320607dd1e6217be5f0f7f68db79465d0fb6d9;p=gitmo%2FMoose.git

this speling test is really useful. fixed a whole bunch of types in the cookbook
---

diff --git a/lib/Moose/Cookbook/Basics/Recipe10.pod b/lib/Moose/Cookbook/Basics/Recipe10.pod
index 7031140..8cafe18 100644
--- a/lib/Moose/Cookbook/Basics/Recipe10.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe10.pod
@@ -230,7 +230,7 @@ The three techniques we used, overloading, subtypes, and coercion,
 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>.
diff --git a/lib/Moose/Cookbook/Basics/Recipe3.pod b/lib/Moose/Cookbook/Basics/Recipe3.pod
index c08e4c4..f4063c2 100644
--- a/lib/Moose/Cookbook/Basics/Recipe3.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe3.pod
@@ -59,7 +59,7 @@ constraint is C<Any>, which means literally means it can contain
 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 @@ object.
 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
diff --git a/lib/Moose/Cookbook/Basics/Recipe4.pod b/lib/Moose/Cookbook/Basics/Recipe4.pod
index 7998a8d..2da9616 100644
--- a/lib/Moose/Cookbook/Basics/Recipe4.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe4.pod
@@ -107,7 +107,7 @@ existing CPAN tools for data validation.
 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 @@ method modifier:
 
 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
diff --git a/lib/Moose/Cookbook/Meta/Recipe2.pod b/lib/Moose/Cookbook/Meta/Recipe2.pod
index 013ed4c..f9e3db5 100644
--- a/lib/Moose/Cookbook/Meta/Recipe2.pod
+++ b/lib/Moose/Cookbook/Meta/Recipe2.pod
@@ -108,7 +108,7 @@ you can call methods on it like this:
 
 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 @@ Then we need to register our metaclass with Moose:
   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 @@ Finally, we use it for an attribute:
       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
diff --git a/lib/Moose/Cookbook/Meta/Recipe3.pod b/lib/Moose/Cookbook/Meta/Recipe3.pod
index bf3bc74..673d7fb 100644
--- a/lib/Moose/Cookbook/Meta/Recipe3.pod
+++ b/lib/Moose/Cookbook/Meta/Recipe3.pod
@@ -73,7 +73,7 @@ L<Moose::Cookbook::Meta::Recipe2>. Please read that recipe first.
 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
diff --git a/lib/Moose/Cookbook/Meta/Recipe5.pod b/lib/Moose/Cookbook/Meta/Recipe5.pod
index b357ed4..5a82598 100644
--- a/lib/Moose/Cookbook/Meta/Recipe5.pod
+++ b/lib/Moose/Cookbook/Meta/Recipe5.pod
@@ -26,7 +26,7 @@ Moose::Cookbook::Meta::Recipe5 - The "table" attribute as a metaclass trait
 =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>.
 
diff --git a/lib/Moose/Cookbook/Roles/Recipe1.pod b/lib/Moose/Cookbook/Roles/Recipe1.pod
index 5dc60cb..f36ce03 100644
--- a/lib/Moose/Cookbook/Roles/Recipe1.pod
+++ b/lib/Moose/Cookbook/Roles/Recipe1.pod
@@ -77,7 +77,7 @@ Roles have two primary purposes: as interfaces, and as a means of code
 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';
diff --git a/lib/Moose/Manual/BestPractices.pod b/lib/Moose/Manual/BestPractices.pod
index 56c9709..0c74d75 100644
--- a/lib/Moose/Manual/BestPractices.pod
+++ b/lib/Moose/Manual/BestPractices.pod
@@ -40,7 +40,7 @@ immutable speeds up a lot of things, most notably object construction.
 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 @@ will be faster when immutabilized.
 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
diff --git a/xt/pod_spell.t b/xt/pod_spell.t
index 31c3ebd..a59fd44 100644
--- a/xt/pod_spell.t
+++ b/xt/pod_spell.t
@@ -74,6 +74,7 @@ clearers
 composable
 Debuggable
 DEMOLISHALL
+hardcode
 immutabilization
 immutabilize
 introspectable
@@ -81,6 +82,7 @@ metaclass
 Metaclass
 METACLASS
 metaclass's
+metadata
 MetaObject
 metaprogrammer
 metarole
@@ -105,6 +107,8 @@ destructor
 destructors
 DWIM
 hashrefs
+immutabilize
+immutabilized
 inline
 invocant
 invocant's