From: Eric Wilhelm Date: Sun, 6 Aug 2006 06:35:20 +0000 (+0000) Subject: lib/Moose/Cookbook/*.pod - POD spelling, grammar, formatting fixes X-Git-Tag: 0_12~11 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=e08c54f595734e63385e2a4a758b9655c302bf41;p=gitmo%2FMoose.git lib/Moose/Cookbook/*.pod - POD spelling, grammar, formatting fixes --- diff --git a/lib/Moose/Cookbook/Recipe2.pod b/lib/Moose/Cookbook/Recipe2.pod index 6648416..2b8c4d9 100644 --- a/lib/Moose/Cookbook/Recipe2.pod +++ b/lib/Moose/Cookbook/Recipe2.pod @@ -68,10 +68,10 @@ new attribute feature, that of a default value. has 'balance' => (isa => 'Int', is => 'rw', default => 0); -This tells is that a B has a C attribute, -which is has the C type constraint, a read/write accessor, +This tells us that a B has a C attribute, +which has the C type constraint, a read/write accessor, and a default value of C<0>. This means that every instance of -B that is created will have it's C slot +B that is created will have its C slot initialized to C<0>. Very simple really :) Next come the methods. The C and C methods @@ -95,7 +95,7 @@ you define, a corresponding type constraint will be created for that class. This means that in the first recipe, a C and C type constraint were created, and in this recipe, both a C and a C type constraint were -created. Moose does this as a convience for you so that your +created. Moose does this as a convenience for you so that your class model and the type constraint model can both be kept in sync with one another. In short, Moose makes sure that it will just DWIM (1). @@ -142,13 +142,13 @@ author of the B subclass does not need to remember to call C and to pass it the C<$amount> argument. Instead the method modifier assures that all arguments make it to the superclass method correctly. But this is actually more -than just a convience for forgetful programmers, it also helps +than just a convenience for forgetful programmers, it also helps isolate subclasses from changes in the superclasses. For instance, if B were to add an additional argument of some kind, the version of B which uses C would not pass that extra argument -correctly. Whereas the method modifier version of would pass -all arguments along correctly automatically. +correctly. Whereas the method modifier version would automatically pass +along all arguments correctly. Just as with the first recipe, object instantiation is a fairly normal process, here is an example: @@ -214,4 +214,4 @@ L This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. -=cut \ No newline at end of file +=cut diff --git a/lib/Moose/Cookbook/Recipe3.pod b/lib/Moose/Cookbook/Recipe3.pod index b7ad6d6..19e7d0e 100644 --- a/lib/Moose/Cookbook/Recipe3.pod +++ b/lib/Moose/Cookbook/Recipe3.pod @@ -54,7 +54,7 @@ instance has a C slot to hold an abitrary value, a C slot to hold the right node, a C slot to hold the left node, and finally a C slot to hold a reference back up the tree. -Now, lets start with the code, our first attribute is the C +Now, let's start with the code, our first attribute is the C slot, defined as such: has 'node' => (is => 'rw', isa => 'Any'); @@ -64,13 +64,13 @@ read/write accessor generated for it, and has a type constraint on it. The new item here is the type constraint of C. In the type constraint heirarchy in L, the C constraint is the "root" of the hierarchy. It means exactly what it -says, it allows anything to pass. Now, you could just as easily of left -the C out, and left the C slot unconstrainted and gotten the -same behavior. But here, we are really including the type costraint +says, it allows anything to pass. Now, you could just as easily have +left out the C, left the C slot unconstrained and gotten the +same behavior. But here, we are really including the type constraint for the benefit of other programmers, not the computer. It makes clear my intent that the C can be of any type, and that the class is a polymorphic container. Next, lets move onto the C -slot. +slot. has 'parent' => ( is => 'rw', @@ -80,7 +80,7 @@ slot. ); As you already know from reading the previous recipes, this code -tells you that C gets a read/write accessor, is constrainted +tells you that C gets a read/write accessor and is constrained to only accept instances of B. You will of course remember from the second recipe that the C type constraint is automatically created for us by Moose. @@ -112,7 +112,7 @@ one here. default => sub { BinaryTree->new(parent => $_[0]) }, ); -You already know what the C, C and C<>predicate> options +You already know what the C, C and C options do, but now we have two more new options. These two options are actually linked together, in fact, you cannot use the C option unless you have set the C option. The class @@ -146,8 +146,8 @@ default value), we also pass in the instance where the slot will be stored. This added feature can come in quite handy at times, as is illustrated above, with this code: - default => sub { BinaryTree->new(parent => $_[0]) }, - + default => sub { BinaryTree->new(parent => $_[0]) }, + The default value being generated is a new C instance for the C (or C) slot. Here we set up the parental relationship by passing the current instance to the constructor. @@ -173,12 +173,12 @@ However, if you I the slot, then at that I moment (and no sooner), the slot will be populated with the value of the C option. -This option is what allows the B class to instantiate -objects without fear of the I -I mentioned earlier. +This option is what allows the B class to instantiate +objects without fear of the I +mentioned earlier. -So, we have descibed a quite complex set of behaviors here, and not -one method has needed to be written. But wait, we can't get away that +So, we have described a quite complex set of behaviors here, and not +one method had to be written. But wait, we can't get away that easily. The autogenerated C and C accessors are not completely correct. They will not install the parental relationships that we need. We could write our own accessors, but that would require @@ -211,7 +211,7 @@ possibilities of Moose's attribute mechanism. I hope that it has opened your mind to the powerful possibilities of Moose. In the next recipe we explore how we can create custom subtypes and take advantage of the plethora of useful modules out on CPAN with Moose. - + =head1 FOOTNOTES =over 4 diff --git a/lib/Moose/Cookbook/Recipe4.pod b/lib/Moose/Cookbook/Recipe4.pod index 944a737..5ae2daa 100644 --- a/lib/Moose/Cookbook/Recipe4.pod +++ b/lib/Moose/Cookbook/Recipe4.pod @@ -109,9 +109,9 @@ how that can be useful for specifying specific type constraints without having to build an entire class to represent them. We will also show how this feature can be used to leverage the usefulness of CPAN modules. In addition to this, we will also -introduce another attribute option as well. +introduce another attribute option. -Lets first get into the C features. In the B
+Let's first get into the C features. In the B
class we have defined two subtypes. The first C uses the L module, which provides two hashes which can be used to do existence checks for state names and their two letter @@ -159,7 +159,7 @@ and share them among many different classes (avoiding unneeded duplication) because type constraints are stored by string in a global registry and always accessible to C. -With these two subtypes and some attributes, we pretty much define +With these two subtypes and some attributes, we have defined as much as we need for a basic B
class. Next we define a basic B class, which itself has an address. As we saw in earlier recipes, we can use the C
type constraint that @@ -177,13 +177,13 @@ the B constructor, and that the C accessor cannot accept an undefined value for the slot. The result is that C should always have a value. -The next attribute option is not actually a new one, but a new varient +The next attribute option is not actually new, but a new variant of options we have already introduced. has 'employees' => (is => 'rw', isa => subtype ArrayRef => where { (blessed($_) && $_->isa('Employee') || return) for @$_; 1 }); - + Here, instead of passing a string to the C option, we are passing an anyonomous subtype of the C type constraint. This subtype basically checks that all the values in the ARRAY ref are instance of @@ -216,7 +216,7 @@ and full of I instances of B. The next place we need to address is the C read/write accessor (see the C attribute declaration above). This accessor will properly check the type constraint, but we need to add -so additional behavior. For this we use an C method modifier +some additional behavior. For this we use an C method modifier like so: after 'employees' => sub { @@ -233,7 +233,7 @@ check has already happened, so we can just check for defined-ness on the C<$employees> argument. At this point, our B class is complete. Next comes our B -class and it's subclass the previously mentioned B class. +class and its subclass the previously mentioned B class. The B class should be obvious to you at this point. It has a few C attributes, and the C slot has an additional @@ -245,17 +245,17 @@ point. It requires a C, and maintains a weakend reference to a B<Company> instance. The only new item, which we have seen before in examples, but never in the recipe itself, is the C<override> method modifier. - + override 'full_name' => sub { my $self = shift; super() . ', ' . $self->title }; -This just tells Moose that I am intetionally overriding the superclass +This just tells Moose that I am intentionally overriding the superclass C<full_name> method here, and adding the value of the C<title> slot at the end of the employee's full name. -And thats about it. +And that's about it. Once again, as with all the other recipes, you can go about using these classes like any other Perl 5 class. A more detailed example of @@ -271,9 +271,9 @@ more code a non-Moose plain old Perl 5 version of this recipe would have been (including all the type constraint checks, weak references, etc). And of course, this recipe also introduced the C<subtype> keyword, and -it's usefulness within the Moose toolkit. In the next recipe we will +its usefulness within the Moose toolkit. In the next recipe we will focus more on subtypes, and introduce the idea of type coercion as well. - + =head1 FOOTNOTES =over 4 @@ -306,4 +306,4 @@ L<http://www.iinteractive.com> This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. -=cut \ No newline at end of file +=cut