Some prose cleanups

diff --git a/lib/Moose/Cookbook/Recipe22.pod b/lib/Moose/Cookbook/Recipe22.pod
index 3fec735..1087cc2 100644 (file)
--- a/lib/Moose/Cookbook/Recipe22.pod
+++ b/lib/Moose/Cookbook/Recipe22.pod
@@ -25,8 +25,8 @@ Moose::Cookbook::Recipe22 - The attribute trait example
 
     has url => (
         traits => [qw/Labeled/],
-        isa    => 'Str',
         is     => 'rw',
+        isa    => 'Str',
         label  => "The site's URL",
     );
 
@@ -72,10 +72,10 @@ first.
 In Recipe 21, we created an attribute metaclass that gives attributes a "label"
 that can be set in L<Moose/has>. That works well until you want a second
 meta-attribute, or until you want to adjust the behavior of the attribute. You
-could have a specialized attribute metaclass for your application that does it
-all. However, you may want different attributes to have different behaviors. So
-you may end up with a unique attribute metaclass for B<every single attribute>,
-with a lot of code copying and pasting.
+could define a specialized attribute metaclass to use in every attribute.
+However, you may want different attributes to have different behaviors. You
+might end up with a unique attribute metaclass for B<every single attribute>,
+with a lot of code copying and pasting!
 
 Or, if you've been drinking deeply of the Moose kool-aid, you'll have a role
 for each of the behaviors. One role would give a label meta-attribute. Another
@@ -93,10 +93,10 @@ Roles that apply to metaclasses have a special name: traits. Don't let the
 change in nomenclature fool you, B<traits are just roles>.
 
 L<Moose/has> provides a C<traits> option. It takes a list of trait names to
-compose into an anonymous metaclass. So you do still have a bunch of attribute
-metaclasses that do nothing but compose a bunch of roles, but they're managed
-automatically by Moose. You don't need to declare them in advance, or worry
-whether changing one will affect some other attribute.
+compose into an anonymous metaclass. That means you do still have a bunch of
+attribute metaclasses that do nothing but compose a bunch of roles, but they're
+managed automatically by Moose. You don't need to declare them in advance, or
+worry whether changing one will affect some other attribute.
 
 What can traits do? Anything roles can do. They can add or refine attributes,
 wrap methods, provide more methods, define an interface, etc. The only
@@ -107,7 +107,7 @@ user-level class.
 
 A side-by-side look of the code examples in this recipe and recipe 21 should
 indicate that defining and using a trait is very similar to defining and using
-a new attribute metaclass. Only a few lines have changed.
+a new attribute metaclass.
 
     package MyApp::Meta::Attribute::Trait::Labeled;
     use Moose::Role;
@@ -126,35 +126,35 @@ in our application.
     package Moose::Meta::Attribute::Custom::Trait::Labeled;
     sub register_implementation { 'MyApp::Meta::Attribute::Trait::Labeled' }
 
-Much like when we define a new attribute metaclass, we can provide a shortcut
+Much like when we define a new attribute metaclass, we can provide a shorthand
 name for the trait. Moose looks at the C<register_implementation> method in
 C<Moose::Meta::Attribute::Custom::Trait::$TRAIT_NAME> to find the full
 name of the trait.
 
 Now we begin writing our application logic. I'll only cover what has changed
-between recipe 21 and this.
+since recipe 21.
 
     has url => (
         traits => [qw/Labeled/],
-        isa    => 'Str',
         is     => 'rw',
+        isa    => 'Str',
         label  => "The site's URL",
     );
 
 L<Moose/has> provides a C<traits> option. Just pass the list of trait names and
 it will compose them together to form the (anonymous) attribute metaclass used
-by this attribute.
+by the attribute. We provide a label for the attribute in the same way.
 
-            # print the label if available
-            if ($attribute->does('MyApp::Meta::Attribute::Trait::Labeled')
-                && $attribute->has_label) {
-                    print $attribute->label;
-            }
+    # print the label if available
+    if ($attribute->does('MyApp::Meta::Attribute::Trait::Labeled')
+        && $attribute->has_label) {
+            print $attribute->label;
+    }
 
-Previously, this asked the question "Does this attribute use our attribute
-metaclass?" But since we're now using a trait, we ask "Does this attribute's
-metaclass do the C<Labeled> role?" If not, it won't have the C<has_label>
-method, and so it would be an error to blindly call
+Previously, this code asked the question "Does this attribute use our attribute
+metaclass?" Since we're now using a trait, we ask "Does this attribute's
+metaclass do the C<Labeled> role?" If not, the attribute metaclass won't have
+the C<has_label> method, and so it would be an error to blindly call
 C<< $attribute->has_label >>.
 
 That's all. Everything else is the same!
@@ -162,7 +162,7 @@ That's all. Everything else is the same!
 =head1 CONCLUSION
 
 If you're extending your attributes, it's easier and more flexible to provide
-composable bits of behavior, rather than subclassing L<Moose::Meta::Attribute>.
+composable bits of behavior than to subclass L<Moose::Meta::Attribute>.
 Using traits (which are just roles applied to a metaclass!) let you choose
 exactly which behaviors each attribute will have. Moose makes it easy to create
 attribute metaclasses on the fly by providing a list of trait names to