Moose::Cookbook::Recipe1:

* POD work: mainly grammar tweaks.

diff --git a/lib/Moose/Cookbook/Recipe1.pod b/lib/Moose/Cookbook/Recipe1.pod
index 71ed4d0..f9382d5 100644 (file)
--- a/lib/Moose/Cookbook/Recipe1.pod
+++ b/lib/Moose/Cookbook/Recipe1.pod
@@ -39,38 +39,38 @@ example found in the classic K&R C book as well, and many other
 places. And now, onto the code:
 
 As with all Perl 5 classes, a Moose class is defined in a package. 
-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.
+Moose now handles turning on C<strict> and C<warnings> for you, so 
+all you need to do is say C<use Moose>, and no kittens will die.
 
-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.
+By loading Moose, we are enabling the loading of the Moose
+"environment" into our package. This means that we import some
+functions which serve as Moose "keywords". These aren't anything
+fancy, just plain old exported functions.
 
 Another important thing happens at this stage as well. Moose will 
 automatically set your package's superclass to be L<Moose::Object>.
-The reason we do this, is so that we can be sure that you will 
-inherit from L<Moose::Object> and get the benefits that provides 
-(see the L<Moose::Object> for those details). However, you don't 
+The reason we do this, is so that we can be sure that your class
+will inherit from L<Moose::Object> and get the benefits that
+provides (see L<Moose::Object> for details). However, you don't 
 actually I<have> to inherit from L<Moose::Object> if you don't  
-want to, all other features of Moose are still accessible to you.
+want to. All Moose features will still be accessible to you.
 
 Now, onto the keywords. The first one we see here is C<has>, which 
-defines an instance attribute in your class. 
+defines an instance attribute in your class:
 
   has 'x' => (isa => 'Int', is => 'ro');
 
-This will create an attribute named C<x>, it will expect that the 
+This will create an attribute named C<x>, which will expect the 
 value stored in the attribute to pass the type constraint C<Int> (1), 
 and the accessor generated for this attribute will be read-only 
 (abbreviated as C<ro>).
 
-The next C<has> line is very similar, with only one difference.
+The next C<has> line is very similar, with only one difference:
 
   has 'y' => (isa => 'Int', is => 'rw');
 
-For the C<y> attribute a read/write accessor will be generated 
-(abbreviated as C<rw>). 
+A read/write (abbreviated as C<rw>) accessor will be generated for
+the C<y> attribute.
 
 At this point the attributes have been defined, and it is time to 
 define our methods. In Moose, as with regular Perl 5 OO, a method 
@@ -105,7 +105,7 @@ where C<use base> will C<push> values onto the package's C<@ISA>. It
 is my opinion that the behavior of C<extends> is more intuitive in 
 that it is more explicit about defining the superclass relationship.
 
-A small digression here, both Moose and C<extends> support multiple 
+A small digression here: both Moose and C<extends> support multiple 
 inheritance. You simply pass all the superclasses to C<extends>, 
 like so:
 
@@ -119,7 +119,7 @@ a new attribute for B<Point3D> called C<z>.
 As with B<Point>'s C<x> and C<y> attributes, this attribute has a 
 type constraint of C<Int>, but it differs in that it does B<not> 
 ask for any autogenerated accessors. The result being (aside from 
-breaking object encapsulation), that C<x> is a private attribute.
+broken object encapsulation) that C<x> is a private attribute.
 
 Next comes another Moose feature which we call method "modifiers" 
 (or method "advice" for the AOP inclined). The modifier used here 
@@ -147,7 +147,7 @@ would get the same results with this code:
   }
 
 You could also use another Moose method modifier, C<override> here, 
-and get the same results again. Here is how that would look.
+and get the same results again. Here is how that would look:
 
   override 'clear' => sub {
       my $self = shift;
@@ -159,9 +159,9 @@ The C<override> modifier allows you to use the C<super> keyword
 within it to dispatch to the superclass's method in a very Ruby-ish 
 style.
 
-Now of course, what use is a class if you cant instantiate objects 
-with it. Now since B<Point> inherits from L<Moose::Object>, it will 
-inherit the default L<Moose::Object> constructor called C<new>. Here 
+Now, of course, what use is a class if you can't instantiate objects 
+with it? Since B<Point> inherits from L<Moose::Object>, it will also
+inherit the default L<Moose::Object> constructor: C<new>. Here 
 are two examples of how that is used:
 
   my $point = Point->new(x => 1, y => 2);   
@@ -179,7 +179,7 @@ done, you can refer to the F<t/001_recipe.t> test file.
 =head1 CONCLUSION
 
 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 
+Moose to build your Perl 5 classes. The next recipe will build upon 
 the basics shown here with more complex attributes and methods. 
 Please read on :)
 
@@ -190,16 +190,16 @@ Please read on :)
 =item (1)
 
 Several default type constraints are provided by Moose, of which 
-C<Int> is one. For more information on the built-in type constraints 
+C<Int> is one. For more information on the builtin type constraints 
 and the type constraint system in general, see the 
 L<Moose::Util::TypeConstraints> documentation.
 
 =item (2)
 
 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 interchangeable, it is advised that you avoid direct 
-instance access, like that which is shown above.
+structures such as blessed ARRAY refs and such. If you want your
+Moose classes to be interchangeable, it is advisable to avoid
+direct instance access, like that shown above.
 
 =back