From: Robert Boone Date: Fri, 6 Apr 2007 03:47:09 +0000 (+0000) Subject: Spelling corrections. X-Git-Tag: 0_21~25 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=4711f5f709b4363d26ed39068155e74addb247f2;p=gitmo%2FMoose.git Spelling corrections. --- diff --git a/lib/Moose/Cookbook.pod b/lib/Moose/Cookbook.pod index b85baa5..b1ad8a6 100644 --- a/lib/Moose/Cookbook.pod +++ b/lib/Moose/Cookbook.pod @@ -7,7 +7,7 @@ Moose::Cookbook - How to cook a Moose =head1 DESCRIPTION -The Moose cookbook is a series of recipies taken from the Moose +The Moose cookbook is a series of recipes taken from the Moose test suite. Each recipe presents some code, which demonstrates some of the features of Moose, and then proceeds to explain the details of the code. diff --git a/lib/Moose/Cookbook/FAQ.pod b/lib/Moose/Cookbook/FAQ.pod index 55fa488..69a972c 100644 --- a/lib/Moose/Cookbook/FAQ.pod +++ b/lib/Moose/Cookbook/FAQ.pod @@ -3,7 +3,7 @@ =head1 NAME -Moose::Cookbook::FAQ - Frequenty asked questions about Moose +Moose::Cookbook::FAQ - Frequently asked questions about Moose =head1 FREQUENTLY ASKED QUESTIONS @@ -28,7 +28,7 @@ Yes and No. The external API, the one 90% of users will interact with, is B and any changes B. The introspection API is I stable, I still reserve the right to tweak that if needed, but I will do my -absolute best to maintain backwards comptability here as well. +absolute best to maintain backwards compatibility here as well. =head3 I heard Moose is slow, is this true? @@ -46,13 +46,13 @@ available for getting the speed you need. Currently we have the option of making your classes immutable as a means of boosting speed. This will mean a larger compile time cost, but the runtime speed increase (especially in object -construction) is pretty signifigant. This is not very well +construction) is pretty significant. This is not very well documented yet, so please ask on the list of on #moose for more information. We are also discussing and experimenting with L, and the idea of compiling highly optimized C<.pmc> files. And -we have also mapped out some core methods as canidates for +we have also mapped out some core methods as candidates for conversion to XS. =head3 When will Moose be 1.0 ready? @@ -74,13 +74,13 @@ Ideally, you should never write your own C method, and should use Moose's other features to handle your specific object construction needs. Here are a few scenarios, and the Moose way to solve them; -If you need to call initializtion code post instance construction, +If you need to call initialization code post instance construction, then use the C method. This feature is taken directly from -Perl 6. Every C method in your inheritence chain is called +Perl 6. Every C method in your inheritance chain is called (in the correct order) immediately after the instance is constructed. This allows you to ensure that all your superclasses are initialized properly as well. This is the best approach to take (when possible) -because it makes subclassing your class much easier. +because it makes sub classing your class much easier. If you need to affect the constructor's parameters prior to the instance actually being constructed, you have a number of options. @@ -106,11 +106,11 @@ along with any issues C might add as well. In short, try to use C and coercions, they are your best bets. -=head3 How do I make non-Moose constuctors work with Moose? +=head3 How do I make non-Moose constructors work with Moose? Moose provides it's own constructor, but it does it by making all Moose-based classes inherit from L. When inheriting -from a non-Moose class, the inheritence chain to L +from a non-Moose class, the inheritance chain to L is broken. The simplest way to fix this is to simply explicitly inherit from L yourself. However, this does not always fix the issue of a constructor. Here is a basic example of @@ -119,7 +119,7 @@ how this can be worked around: package My::HTML::Template; use Moose; - # explict inheritence + # explicit inheritance extends 'HTML::Template', 'Moose::Object'; # explicit constructor @@ -140,7 +140,7 @@ HASH refs). Other techniques can be used as well, such as creating the object using C, but calling the inherited non-Moose -class's initializtion methods (if available). +class's initialization methods (if available). It is also entirely possible to just rely on HASH autovivification to create the slot's needed for Moose based attributes. Although @@ -234,7 +234,7 @@ Still another option is to write a custom attribute metaclass, which is also outside the scope of this document, but I would be happy to explain it on #moose or the mailing list. -=head2 Method Modfiers +=head2 Method Modifiers =head3 How can I affect the values in C<@_> using C? diff --git a/lib/Moose/Cookbook/Recipe1.pod b/lib/Moose/Cookbook/Recipe1.pod index 30320bd..71ed4d0 100644 --- a/lib/Moose/Cookbook/Recipe1.pod +++ b/lib/Moose/Cookbook/Recipe1.pod @@ -42,7 +42,7 @@ As with all Perl 5 classes, a Moose class is defined in a package. Moose now handles turning C and C on for you, so all you need do is say C, and no kittens will die. -By loading Moose, we are enabeling the Moose "environment" to be +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. @@ -106,7 +106,7 @@ is my opinion that the behavior of C is more intuitive in that it is more explicit about defining the superclass relationship. A small digression here, both Moose and C support multiple -inheritence. You simply pass all the superclasses to C, +inheritance. You simply pass all the superclasses to C, like so: extends 'Foo', 'Bar', 'Baz'; @@ -178,7 +178,7 @@ done, you can refer to the F test file. =head1 CONCLUSION -I hope this recipe has given you some explaination of how to use +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 the basics shown here with more complex attributes and methods. Please read on :) @@ -198,7 +198,7 @@ L documentation. 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 interchangable, it is advised that you avoid direct +classes to be interchangeable, it is advised that you avoid direct instance access, like that which is shown above. =back @@ -210,7 +210,7 @@ instance access, like that which is shown above. =item Method Modifiers The concept of method modifiers is directly ripped off from CLOS. A -great explaination of them can be found by following this link. +great explanation of them can be found by following this link. L diff --git a/lib/Moose/Cookbook/Recipe2.pod b/lib/Moose/Cookbook/Recipe2.pod index bbd4788..7ec039b 100644 --- a/lib/Moose/Cookbook/Recipe2.pod +++ b/lib/Moose/Cookbook/Recipe2.pod @@ -71,7 +71,7 @@ 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 -should be fairly self explanitory, they are nothing specific to +should be fairly self explanatory, they are nothing specific to Moose, just your standard Perl 5 OO. Now, onto the B class. As you know from the @@ -163,7 +163,7 @@ these classes can be found in the F test file. The aim of this recipe was to take the knowledge learned in the first recipe and expand upon it within a more realistic use case. I hope that this recipe has accomplished this goal. The next -recipe will expand even more upon the capabilties of attributes +recipe will expand even more upon the capabilities of attributes in Moose to create a behaviorally sophisticated class almost entirely defined by attributes. @@ -187,7 +187,7 @@ please refer to the L documentation. =over 4 -=item Acknowledgement +=item Acknowledgment The BankAccount example in this recipe is directly taken from the examples in this chapter of "Practical Common Lisp". A link to that diff --git a/lib/Moose/Cookbook/Recipe3.pod b/lib/Moose/Cookbook/Recipe3.pod index cda8990..40898e9 100644 --- a/lib/Moose/Cookbook/Recipe3.pod +++ b/lib/Moose/Cookbook/Recipe3.pod @@ -48,7 +48,7 @@ complex behaviors. The class in this recipe is a classic binary tree, each node in the tree is represented by an instance of the B class. Each -instance has a C slot to hold an abitrary value, a C +instance has a C slot to hold an arbitrary 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. @@ -57,10 +57,10 @@ slot, defined as such: has 'node' => (is => 'rw', isa => 'Any'); -If you recall from the previous recipies, this slot will have a +If you recall from the previous recipes, this slot will have a 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 hierarchy 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 have left out the C, left the C slot unconstrained and gotten the diff --git a/lib/Moose/Cookbook/Recipe4.pod b/lib/Moose/Cookbook/Recipe4.pod index 12b5099..a41c82f 100644 --- a/lib/Moose/Cookbook/Recipe4.pod +++ b/lib/Moose/Cookbook/Recipe4.pod @@ -136,7 +136,7 @@ C constraint, thereby only allowing valid state names or state codes to be stored in the C slot. The next C, does pretty much the same thing using the -L module, and constrainting the C slot. +L module, and constraining the C slot. subtype USZipCode => as Value @@ -177,7 +177,7 @@ of options we have already introduced. }); Here, instead of passing a string to the C option, we are passing -an anyonomous subtype of the C type constraint. This subtype +an anonymous subtype of the C type constraint. This subtype basically checks that all the values in the ARRAY ref are instance of the B class. @@ -200,7 +200,7 @@ C method (2). } } -The C method will have run after the intial type constraint +The C method will have run after the initial type constraint check, so we can do just a basic existence check on the C param here, and assume that if it does exist, it is both an ARRAY ref and full of I instances of B. @@ -228,12 +228,12 @@ At this point, our B class is complete. Next comes our B 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 +C attributes, and the C slot has an additional C method (which we saw in the previous recipe with the B class). Next the B class, this too should be pretty obvious at this -point. It requires a C, and maintains a weakend reference to a +point. It requires a C<title>, and maintains a weakened 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. @@ -280,7 +280,7 @@ as well. The C<BUILD> method is called by C<Moose::Object::BUILDALL>, which is called by C<Moose::Object::new>. C<BUILDALL> will climb the object -inheritence graph and call the approriate C<BUILD> methods in the +inheritance graph and call the appropriate C<BUILD> methods in the correct order. =back diff --git a/lib/Moose/Cookbook/Recipe5.pod b/lib/Moose/Cookbook/Recipe5.pod index 128dc92..f1100e8 100644 --- a/lib/Moose/Cookbook/Recipe5.pod +++ b/lib/Moose/Cookbook/Recipe5.pod @@ -176,7 +176,7 @@ This recipe illustrated the power of coercions to build a more flexible and open API for your accessors, while still retaining all the safety that comes from using Moose's type constraints. Using coercions it becomes simple to manage (from a single -location) a consisten API not only across multiple accessors, +location) a consistent API not only across multiple accessors, but across multiple classes as well. In the next recipe, we will introduce roles, a concept originally diff --git a/lib/Moose/Cookbook/WTF.pod b/lib/Moose/Cookbook/WTF.pod index b0dfa8a..aa84b02 100644 --- a/lib/Moose/Cookbook/WTF.pod +++ b/lib/Moose/Cookbook/WTF.pod @@ -72,7 +72,7 @@ because of the order in which classes are constructed, Moose would overwrite your custom accessor. You wouldn't want that would you? -=head2 Method Modfiers +=head2 Method Modifiers =head3 How come I can't change C<@_> in a C<before> modifier?