From: Lars Dieckow Date: Wed, 4 Feb 2009 14:09:15 +0000 (+0000) Subject: more typo fixes X-Git-Tag: 0.68~9 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=6549b0d1ae8b084898ac2d8ad60d6a57cccf4124;p=gitmo%2FMoose.git more typo fixes --- diff --git a/lib/Moose.pm b/lib/Moose.pm index 8c210bf..5f87f39 100644 --- a/lib/Moose.pm +++ b/lib/Moose.pm @@ -762,7 +762,7 @@ B allowed to I one. =item I You are allowed to B additional traits to the C definition. -These traits will be composed into the attribute, but pre-existing traits +These traits will be composed into the attribute, but preexisting traits B overridden, or removed. =back @@ -1015,7 +1015,7 @@ early ideas/feature-requests/encouragement/bug-finding. =item L -This is the official web home of Moose, it contains links to our public SVN repo +This is the official web home of Moose, it contains links to our public SVN repository as well as links to a number of talks and articles on Moose and Moose related technologies. @@ -1100,7 +1100,7 @@ Adam (Alias) Kennedy Anders (Debolaz) Nor Berle -Nathan (kolibre) Gray +Nathan (kolibrie) Gray Christian (chansen) Hansen diff --git a/lib/Moose/Cookbook.pod b/lib/Moose/Cookbook.pod index c5132b5..77e50a4 100644 --- a/lib/Moose/Cookbook.pod +++ b/lib/Moose/Cookbook.pod @@ -39,7 +39,7 @@ modifier in a subclass. Demonstrates several attribute features, including types, weak references, predicates ("does this object have a foo?"), defaults, and -lazy attribute uction. +lazy attribute construction. =item L - Subtypes, and modeling a simple B class hierarchy diff --git a/lib/Moose/Cookbook/Basics/Recipe10.pod b/lib/Moose/Cookbook/Basics/Recipe10.pod index 3b1fdf1..343b673 100644 --- a/lib/Moose/Cookbook/Basics/Recipe10.pod +++ b/lib/Moose/Cookbook/Basics/Recipe10.pod @@ -51,7 +51,7 @@ understanding of Moose. =head1 INTRODUCTION -The example in the SYNOPSIS outlines a very basic use of +The example in the L outlines a very basic use of operator overloading and Moose. The example creates a class that allows you to add together two humans and produce a child from them. @@ -64,7 +64,7 @@ While this example works and gets the job done, it really isn't all that useful. To take this a step further let's play around with genes. Particularly the genes that dictate eye color. Why eye color? Because it is simple. There are two genes that have -the most affect on eye color and each person carries two of each +the most effect on eye color and each person carries two of each gene. Now that will be useful! Oh, and don't forget that you were promised some coercion goodness. @@ -76,13 +76,13 @@ First, let's quickly define the techniques that will be used. =head2 Operator Overloading Overloading operators takes a simple declaration of which operator -you want to overload and what method to call. See the perldoc for -overload to see some good, basic, examples. +you want to overload and what method to call. See +L to see some good, basic, examples. =head2 Subtypes Moose comes with 21 default type constraints, as documented in -L. Int, Str, and CodeRef are +L. C, C, and C are all examples. Subtypes give you the ability to inherit the constraints of an existing type, and adding additional constraints on that type. An introduction to type constraints @@ -101,7 +101,7 @@ this can be found in L. As I alluded to in the introduction, there are many different genes that affect eye color. But, there are 2 genes that play -the most prominent role: gey and bey2. To get started let us +the most prominent role: I and I. To get started let us make classes for these genes. =head2 bey2 @@ -115,7 +115,7 @@ make classes for these genes. has 'color' => ( is => 'ro', isa => 'bey2Color' ); -This class is really simple. All we need to know about the bey2 +This class is really simple. All we need to know about the I gene is whether it is of the blue or brown variety. As you can see a type constraint for the color attribute has been created which validates for the two possible colors. @@ -131,14 +131,14 @@ which validates for the two possible colors. has 'color' => ( is => 'ro', isa => 'geyColor' ); -The gey gene is nearly identical to the bey2, except that it +The I gene is nearly identical to I, except that it has a green or blue variety. =head1 EYE COLOR -Rather than throwing the 4 gene object (2xbey, 2xgey2) straight -on to the Human class, let's create an intermediate class that -abstracts the logic behind eye color. This way the Human class +Rather than throwing the 4 gene object (2 x I, 2 x I) straight +on to the C class, let's create an intermediate class that +abstracts the logic behind eye color. This way the C class won't get all cluttered up with the details behind the different characteristics that makes up a Human. @@ -173,10 +173,10 @@ So, we now have a class that can hold the four genes that dictate eye color. This isn't quite enough, as we also need to calculate what the human's actual eye color is as a result of the genes. -As with most genes there are recessive and dominant genes. The bey2 -brown gene is dominant to both blue and green. The gey green gene is -recessive to the brown bey gene and dominant to the blues. Finally, -the bey and gey2 blue genes are recessive to both brown and green. +As with most genes there are recessive and dominant genes. The I +brown gene is dominant to both blue and green. The I green gene is +recessive to the brown I gene and dominant to the blues. Finally, +the I and I blue genes are recessive to both brown and green. sub color { my ($self) = @_; @@ -192,10 +192,10 @@ the bey and gey2 blue genes are recessive to both brown and green. return 'blue'; } -To top it off, if I want to access color(), I want to be really lazy +To top it off, if I want to access C, I want to be really lazy about it. Perl overloading supports the ability to overload the -stringification of an object. So, normally if I did "$eye_color" -I'd get something like "Human::EyeColor=HASH(0xba9348)". What I +stringification of an object. So, normally if I did C<$eye_color> +I'd get something like C. What I really want is "brown", "green", or "blue". To do this you overload the stringification of the object. @@ -204,8 +204,8 @@ the stringification of the object. That's all and good, but don't forget the spawn! Our humans have to have children, and those children need to inherit genes from their parents. Let's use operator overloading so -that we can add (+) together two EyeColor characteristics to -create a new EyeColor that is derived in a similar manner as +that we can add (+) together two C characteristics to +create a new C that is derived in a similar manner as the gene selection in human reproduction. use overload '+' => \&_overload_add, fallback => 1; @@ -233,8 +233,8 @@ the gene selection in human reproduction. What is happening here is we are overloading the addition operator. When two eye color objects are added together -the _overload_add() method will be called with the two -objects on the left and right side of the + as arguments. +the C<_overload_add()> method will be called with the two +objects on the left and right side of the C<+> as arguments. The return value of this method should be the expected result of the addition. I'm not going to go in to the details of how the gene's are selected as it should be @@ -242,11 +242,11 @@ fairly self-explanatory. =head1 HUMAN EVOLUTION -Our original human class in the SYNOPSIS requires very little -change to support the new EyeColor characteristic. All we -need to do is define a new subtype called EyeColor, a new -attribute called eye_color, and just for the sake of simple code -we'll coerce an arrayref of colors in to an EyeColor object. +Our original human class in the L requires very little +change to support the new C characteristic. All we +need to do is define a new subtype called C, a new +attribute called C, and just for the sake of simple code +we'll coerce an arrayref of colors in to an C object. use List::MoreUtils qw( zip ); @@ -262,7 +262,7 @@ we'll coerce an arrayref of colors in to an EyeColor object. has 'eye_color' => ( is => 'ro', isa => 'EyeColor', coerce => 1, required => 1 ); -And then in the _overload_add() of the Human class we modify +And then in the C<_overload_add()> of the C class we modify the creation of the child object to include the addition of the mother and father's eye colors. @@ -280,7 +280,8 @@ and coercion - provide the power to produce simple, flexible, powerful, explicit, inheritable, and enjoyable interfaces. If you want to get your hands on this code all combined together, and -working, download the Moose tarball and look at "t/000_recipes/012_genes.t". +working, download the Moose tarball and look at +F. =head1 NEXT STEPS diff --git a/lib/Moose/Cookbook/Basics/Recipe4.pod b/lib/Moose/Cookbook/Basics/Recipe4.pod index e637dd9..857b9aa 100644 --- a/lib/Moose/Cookbook/Basics/Recipe4.pod +++ b/lib/Moose/Cookbook/Basics/Recipe4.pod @@ -95,11 +95,11 @@ Moose::Cookbook::Basics::Recipe4 - Subtypes, and modeling a simple B cl =head1 DESCRIPTION -In this recipe we introduce the C keyword, and show -how it can be useful for specifying type constraints -without building 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 +In this recipe we introduce the C keyword, and show +how it can be useful for specifying type constraints +without building 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 introduce another attribute option. Let's first look at the C feature. In the B
class we have @@ -116,22 +116,22 @@ module, and perfect for use in a C constraint. || exists $STATES->{state2code}{ uc($_) } ); }; -Because we know that states will be passed to us as strings, we -can make C a subtype of the built-in type constraint -C. This will ensure that anything which is a C will -also pass as a C. Next, we create a constraint specializer -using the C keyword. The value being checked against in -the C clause can be found in the C<$_> variable (1). Our -constraint specializer will then check whether the given string -is either a state name or a state code. If the string meets this +Because we know that states will be passed to us as strings, we +can make C a subtype of the built-in type constraint +C. This will ensure that anything which is a C will +also pass as a C. Next, we create a constraint specializer +using the C keyword. The value being checked against in +the C clause can be found in the C<$_> variable (1). Our +constraint specializer will then check whether the given string +is either a state name or a state code. If the string meets this criteria, then the constraint will pass, otherwise it will fail. We can now use this as we would any built-in constraint, like so: has 'state' => ( is => 'rw', isa => 'USState' ); -The C accessor will now check all values against the -C constraint, thereby only allowing valid state names or -state codes to be stored in the C slot. +The C accessor will now check all values against the +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 is used as the constraint for the C slot. @@ -149,9 +149,9 @@ duplication), since all type constraints are stored in a global registry and always accessible to C. 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 +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 Moose automatically created for us: has 'address' => ( is => 'rw', isa => 'Address' ); @@ -160,22 +160,22 @@ A company also needs a name, so we define that as well: has 'name' => ( is => 'rw', isa => 'Str', required => 1 ); -Here we introduce another attribute option, the C option. -This option tells Moose that C is a required parameter in -the B constructor, and that the C accessor cannot -accept an undefined value for the slot. The result is that C -will always have a value. +Here we introduce another attribute option, the C option. +This option tells Moose that C is a required parameter in +the B constructor, and that the C accessor cannot +accept an undefined value for the slot. The result is that C +will always have a value. -The next attribute option is not actually new, but a new variant +The next attribute option is not actually new, but a new variant of options we have already introduced: has 'employees' => ( is => 'rw', isa => 'ArrayRef[Employee]' ); -Here, we are passing a more complex string to the C option, we -are passing a container type constraint. Container type constraints -can either be C or C with a contained type given -inside the square brackets. This basically checks that all the values -in the ARRAY ref are instances of the B class. +Here, we are passing a more complex string to the C option, we +are passing a container type constraint. Container type constraints +can either be C or C with a contained type given +inside the square brackets. This basically checks that all the values +in the ARRAY ref are instances of the B class. This will ensure that our employees will all be of the correct type. However, the B object (which we will see in a moment) also maintains a @@ -195,13 +195,13 @@ C method (2): } } -The C method will be executed after the initial type constraint +The C method will be executed after the initial type constraint check, so we can simply perform a basic existential check on the C -param here, and assume that if it does exist, it is both an ARRAY ref +parameter here, and assume that if it does exist, it is both an ARRAY ref and contains I instances of B. -The next aspect we need to address is the C read/write -accessor (see the C attribute declaration above). This +The next aspect we need to address is the C read/write +accessor (see the C attribute declaration above). This accessor will correctly check the type constraint, but we need to extend it with some additional processing. For this we use an C method modifier, like so: @@ -215,22 +215,22 @@ like so: } }; -Again, as with the C method, we know that the type constraint -check has already happened, so we can just check for defined-ness on the +Again, as with the C method, we know that the type constraint +check has already happened, so we can just check for definedness on the C<$employees> argument. -At this point, our B class is complete. Next comes our B -class and its subclass, the previously mentioned B class. +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 method (which we saw in the previous recipe with the -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 method (which we saw in the previous recipe with the +B class). -Next, the B class, which should also be pretty obvious at this -point. It requires a C, 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 +Next, the B<Employee> class, which should also be pretty obvious at this +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: override 'full_name' => sub { @@ -238,27 +238,27 @@ modifier: super() . ', ' . $self->title; }; -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 +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 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 +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 usage can be found in F<t/000_recipes/004_recipe.t>. =head1 CONCLUSION -This recipe was intentionally longer and more complex to illustrate both +This recipe was intentionally longer and more complex to illustrate both how easily Moose classes can interact (using class type constraints, etc.) -and the sheer density of information and behaviors which Moose can pack -into a relatively small amount of typing. Ponder for a moment how much -more code a non-Moose plain old Perl 5 version of this recipe would have +and the sheer density of information and behaviors which Moose can pack +into a relatively small amount of typing. Ponder for a moment how much +more code a non-Moose plain old Perl 5 version of this recipe would have been (including all the type constraint checks, weak references, and so on). -And of course, this recipe also introduced the C<subtype> keyword, and -its usefulness within the Moose toolkit. In the next recipe we will +And of course, this recipe also introduced the C<subtype> keyword, and +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 @@ -267,15 +267,15 @@ focus more on subtypes, and introduce the idea of type coercion as well. =item (1) -The value being checked is also passed as the first argument to -the C<where> block as well, so it can also be accessed as C<$_[0]> +The value being checked is also passed as the first argument to +the C<where> block as well, so it can also be accessed as C<$_[0]> as well. =item (2) -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 -inheritance graph and call the appropriate C<BUILD> methods in the +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 +inheritance graph and call the appropriate C<BUILD> methods in the correct order. =back diff --git a/lib/Moose/Cookbook/Basics/Recipe5.pod b/lib/Moose/Cookbook/Basics/Recipe5.pod index 3ab49c9..a77dac4 100644 --- a/lib/Moose/Cookbook/Basics/Recipe5.pod +++ b/lib/Moose/Cookbook/Basics/Recipe5.pod @@ -97,7 +97,7 @@ coercion can help. First, let's declare our coercion: => from 'HashRef' => via { HTTP::Headers->new( %{$_} ) }; -We first tell it that we are attaching the coercion to the 'Header' +We first tell it that we are attaching the coercion to the C<Header> subtype. We then give it a set of C<from> clauses which map other subtypes to coercion routines (through the C<via> keyword). Fairly simple really; however, this alone does nothing. We have to tell our @@ -143,8 +143,8 @@ Then we add the coercion: => from 'Str' => via { URI->new( $_, 'http' ) }; -The first C<from> clause we introduce is for the 'Object' subtype. An -'Object' is simply any C<bless>ed value. This means that if the +The first C<from> clause we introduce is for the C<Object> subtype. An +C<Object> is simply any C<bless>ed value. This means that if the coercion encounters another object, it should use this clause. Now we look at the C<via> block. First it checks to see if the object is a B<URI> instance. Since the coercion process occurs prior to any type @@ -153,12 +153,12 @@ if it does happen, we simply want to pass the instance on through. However, if it is not an instance of B<URI>, then we need to coerce it. This is where L<Params::Coerce> can do its magic, and we can just use its return value. Simple really, and much less work since -we used a module from CPAN :) +we used a module from CPAN. :) -The second C<from> clause is attached to the 'Str' subtype, and -illustrates how coercions can also be used to handle certain 'default' +The second C<from> clause is attached to the C<Str> subtype, and +illustrates how coercions can also be used to handle certain "default" behaviors. In this coercion, we simple take any string and pass it to -the B<URI> constructor along with the default 'http' scheme type. +the B<URI> constructor along with the default C<http> scheme type. And of course, our coercions do nothing unless they are told to, like so: diff --git a/lib/Moose/Cookbook/Basics/Recipe9.pod b/lib/Moose/Cookbook/Basics/Recipe9.pod index 0e5f2ce..2a21eec 100644 --- a/lib/Moose/Cookbook/Basics/Recipe9.pod +++ b/lib/Moose/Cookbook/Basics/Recipe9.pod @@ -66,14 +66,14 @@ attribute>. Here's an example in code: At this point, Moose will call C<< $tree->_build_child_tree() >> in order to populate the C<left> attribute. If we had passed C<left> to -the original constructor, the builer would not be called. +the original constructor, the builder would not be called. =head2 Subclassable There are some differences between C<default> and C<builder>. Because C<builder> is called I<by name>, it goes through Perl's normal inheritance system. This means that builder methods are both -inheritable and overrideable. +inheritable and overridable. For example, we might make a C<BinaryTree> subclass: diff --git a/lib/Moose/Cookbook/Extending/Recipe1.pod b/lib/Moose/Cookbook/Extending/Recipe1.pod index a275021..e151bec 100644 --- a/lib/Moose/Cookbook/Extending/Recipe1.pod +++ b/lib/Moose/Cookbook/Extending/Recipe1.pod @@ -44,7 +44,7 @@ extension. Many of the Moose extensions on CPAN work by providing an attribute metaclass extension. For example, the C<MooseX::AttributeHelpers> -distro provides a new attribute metaclass that lets you delegate +distribution provides a new attribute metaclass that lets you delegate behavior to a non-object attribute (a hashref or simple number). A metaclass extension can be packaged as a subclass or a @@ -103,7 +103,7 @@ Another common Moose extension is a new type for the Moose type system. In this case, you simply create a type in your module. When people load your module, the type is created, and they can refer to it by name after that. The C<MooseX::Types::URI> and -C<MooseX::Types::DateTime> distros are two good examples of how this +C<MooseX::Types::DateTime> distributions are two good examples of how this works. =head1 ROLES VS TRAITS VS SUBCLASSES diff --git a/lib/Moose/Cookbook/Meta/Recipe2.pod b/lib/Moose/Cookbook/Meta/Recipe2.pod index 453add7..4f82d42 100644 --- a/lib/Moose/Cookbook/Meta/Recipe2.pod +++ b/lib/Moose/Cookbook/Meta/Recipe2.pod @@ -73,7 +73,7 @@ can benefit greatly from going more meta. The high-level goal of this recipe's code is to allow each attribute to have a human-readable "label" attached to it. Such labels would be used when showing -data to an end user. In this recipe we label the "url" attribute with "The +data to an end user. In this recipe we label the C<url> attribute with "The site's URL" and create a simple method to demonstrate how to use that label. =head1 REAL ATTRIBUTES 101 @@ -85,7 +85,7 @@ concrete example. has 'x' => ( isa => 'Int', is => 'ro' ); has 'y' => ( isa => 'Int', is => 'rw' ); -Ahh, the veritable x and y of the Point example. Internally, every Point has an +Ah, the veritable x and y of the Point example. Internally, every Point has an x object and a y object. They have methods (such as "get_value") and attributes (such as "is_lazy"). What class are they instances of? L<Moose::Meta::Attribute>. You don't normally see the objects lurking behind @@ -148,7 +148,7 @@ credit: how in the actual hell can you use the MOP to extend itself?) predicate => 'has_label', ); -Hey, this looks pretty reasonable! This is plain jane Moose code. Recipe 1 +Hey, this looks pretty reasonable! This is plain-Jane Moose code. Recipe 1 fare. This is merely making a new attribute. An attribute that attributes have. A meta-attribute. It may sound scary, but it really isn't! Reread L<REAL ATTRIBUTES 101> if this really is terrifying. diff --git a/lib/Moose/Cookbook/Snack/Keywords.pod b/lib/Moose/Cookbook/Snack/Keywords.pod index 132f5af..db1a89a 100644 --- a/lib/Moose/Cookbook/Snack/Keywords.pod +++ b/lib/Moose/Cookbook/Snack/Keywords.pod @@ -100,7 +100,7 @@ your code, like so: no Moose; -This will un-export the keywords that L<Moose> originally exported. The same +This will unexport the keywords that L<Moose> originally exported. The same will also work for L<Moose::Role> and L<Moose::Util::TypeConstraints>. It is general L<Moose> policy that this feature is used. diff --git a/lib/Moose/Cookbook/Snack/Types.pod b/lib/Moose/Cookbook/Snack/Types.pod index 514d623..0448e4f 100644 --- a/lib/Moose/Cookbook/Snack/Types.pod +++ b/lib/Moose/Cookbook/Snack/Types.pod @@ -16,7 +16,7 @@ Moose::Cookbook::Snack::Types - Snippets of code for using Types and Type Constr package main; my $point = eval { - Point->new(x => 'fifty', y => 'fourty'); + Point->new(x => 'fifty', y => 'forty'); }; if($@) { @@ -24,7 +24,7 @@ Moose::Cookbook::Snack::Types - Snippets of code for using Types and Type Constr } my $point; - my $xval = 'fourty-two'; + my $xval = 'forty-two'; my $xattribute = Point->meta->find_attribute_by_name('x'); my $xtype_constraint = $xattribute->type_constraint; if($xtype_constraint->check($xval)) { @@ -41,7 +41,7 @@ type checking. If we try to assign a string value to an attribute that is defined as being of type Int, Moose will die with an explicit error message -saying which attribute failed which type constaint with which +saying which attribute failed which type constraint with which value. The eval example catches this message and displays it. The second example fetches the type constraint instance and asks it to diff --git a/lib/Moose/Cookbook/Style.pod b/lib/Moose/Cookbook/Style.pod index c90a1de..1e5059b 100644 --- a/lib/Moose/Cookbook/Style.pod +++ b/lib/Moose/Cookbook/Style.pod @@ -96,7 +96,7 @@ the C<init_arg> to C<undef> instead of overwriting it in C<BUILD>. If you need to change the way C<@_> is processed, for example for C<< Class->new( $single_param ) >>, use C<BUILDARGS> instead of wrapping -C<new>. This ensures the behavior is subclassible, it keeps this logic +C<new>. This ensures the behavior is subclassable, it keeps this logic independent of the other aspects of construction, and can be made efficient using C<make_immutable>. diff --git a/lib/Moose/Cookbook/WTF.pod b/lib/Moose/Cookbook/WTF.pod index ef194ad..9210857 100644 --- a/lib/Moose/Cookbook/WTF.pod +++ b/lib/Moose/Cookbook/WTF.pod @@ -137,7 +137,7 @@ that the order of composition does not matter (for information on the deeper theory of this read the original traits papers here L<http://www.iam.unibe.ch/~scg/Research/Traits/>). -Because roles are essentially un-ordered, it would be impossible to +Because roles are essentially unordered, it would be impossible to determine the order in which to execute the BUILD methods. As for alternate solutions, there are a couple. @@ -153,15 +153,15 @@ L<Moose::Cookbook::Basics::Recipe3>) =item * -Use attibutes triggers, which fire after an attribute it set, to faciliate +Use attributes triggers, which fire after an attribute it set, to facilitate initialization. These are described in the L<Moose> docs and examples can be found in the test suite. =back -In general, roles should not I<require> intialization, they should either +In general, roles should not I<require> initialization, they should either provide sane defaults or should be documented as needing specific -initialization. One such way to "document" this is to have a seperate +initialization. One such way to "document" this is to have a separate attribute initializer which is required for the role. Here is an example of how to do this: diff --git a/lib/Moose/Manual/Concepts.pod b/lib/Moose/Manual/Concepts.pod index 9820b05..70cac00 100644 --- a/lib/Moose/Manual/Concepts.pod +++ b/lib/Moose/Manual/Concepts.pod @@ -174,14 +174,14 @@ that gets called before or after (or around, etc.) some named method. Moose also comes with a (miniature) type system. This allows you to define types for attributes. Moose has a set of built-in types based -on what Perl provides, such as "Str", "Num", "Bool", "HashRef", etc. +on what Perl provides, such as C<Str>, C<Num>, C<Bool>, C<HashRef>, etc. In addition, every class name in your application can also be used as -a type name. We saw an example using "DateTime" earlier. +a type name. We saw an example using C<DateTime> earlier. Finally, you can define your own types, either as subtypes or entirely new types, with their own constraints. For example, you could define a -type "PosInt", a subtype of "Int" which only allows positive numbers. +type C<PosInt>, a subtype of C<Int> which only allows positive numbers. =head2 Delegation @@ -223,7 +223,7 @@ person has a first and last name. In old school Perl 5, this is often a blessed hash reference. With Moose, you should never need to know what your object instance -actually is. (ok, it's usually a blessed hashref with Moose too) +actually is. (Okay, it's usually a blessed hashref with Moose, too.) =head2 Moose vs old school summary @@ -334,7 +334,7 @@ L<Moose::Meta::TypeConstraint>, L<Moose::Meta::Instance>, and so on. One of the great things about Moose is that if you dig down and find that it does something the "wrong way", you can change it by extending a metaclass. For example, you can have arrayref based objects, you can -make your constructors strict (no unknown params allowed!), you can +make your constructors strict (no unknown parameters allowed!), you can define a naming scheme for attribute accessors, you can make a class a Singleton, and much, much more. diff --git a/lib/Moose/Manual/MethodModifiers.pod b/lib/Moose/Manual/MethodModifiers.pod index 661936b..3325dab 100644 --- a/lib/Moose/Manual/MethodModifiers.pod +++ b/lib/Moose/Manual/MethodModifiers.pod @@ -87,7 +87,7 @@ Moose generates for you, such as an attribute accessor: }; Another use for the before modifier would be to do some sort of -pre-checking on a method call. For example: +prechecking on a method call. For example: before 'size' => sub { my $self = shift; diff --git a/lib/Moose/Manual/MooseX.pod b/lib/Moose/Manual/MooseX.pod index f4212b0..cb575d2 100644 --- a/lib/Moose/Manual/MooseX.pod +++ b/lib/Moose/Manual/MooseX.pod @@ -164,7 +164,7 @@ cool, but still new and experimental. =head2 L<MooseX::Types> This extension helps you build a type library for your application. It -also lets you pre-declare type names and use them as barewords. +also lets you predeclare type names and use them as barewords. use MooseX::Types -declare => ['PosInt']; use MooseX::Types::Moose 'Int'; diff --git a/lib/Moose/Manual/Types.pod b/lib/Moose/Manual/Types.pod index d743b3d..f60c135 100644 --- a/lib/Moose/Manual/Types.pod +++ b/lib/Moose/Manual/Types.pod @@ -78,7 +78,7 @@ L<Moose::Util::TypeConstraints>. It's important to realize that types are not classes (or packages). Types are just objects (L<Moose::Meta::TypeConstraint> objects, to be exact) with a name and a constraint. Moose maintains a -global type registry that lets it convert names like "Num" into the +global type registry that lets it convert names like C<Num> into the appropriate object. However, class names I<can be> type names. When you define a new class diff --git a/lib/Moose/Meta/Attribute.pm b/lib/Moose/Meta/Attribute.pm index 66f10b8..5d56089 100644 --- a/lib/Moose/Meta/Attribute.pm +++ b/lib/Moose/Meta/Attribute.pm @@ -795,12 +795,12 @@ will behave just as L<Class::MOP::Attribute> does. =item B<set_value> - eval { $point->meta->get_attribute('x')->set_value($point, 'fourty-two') }; + eval { $point->meta->get_attribute('x')->set_value($point, 'forty-two') }; if($@) { print "Oops: $@\n"; } -I<Attribute (x) does not pass the type constraint (Int) with 'fourty-two'> +I<Attribute (x) does not pass the type constraint (Int) with 'forty-two'> Before setting the value, a check is made on the type constraint of the attribute, if it has one, to see if the value passes it. If the diff --git a/lib/Moose/Meta/Class.pm b/lib/Moose/Meta/Class.pm index 707abc0..efea6f9 100644 --- a/lib/Moose/Meta/Class.pm +++ b/lib/Moose/Meta/Class.pm @@ -186,7 +186,7 @@ sub construct_instance { my $meta_instance = $class->get_meta_instance; # FIXME: # the code below is almost certainly incorrect - # but this is foreign inheritence, so we might + # but this is foreign inheritance, so we might # have to kludge it in the end. my $instance = $params->{'__INSTANCE__'} || $meta_instance->create_instance(); foreach my $attr ($class->compute_all_applicable_attributes()) { diff --git a/lib/Moose/Meta/Method/Augmented.pm b/lib/Moose/Meta/Method/Augmented.pm index 12e7d60..ab920ad 100644 --- a/lib/Moose/Meta/Method/Augmented.pm +++ b/lib/Moose/Meta/Method/Augmented.pm @@ -25,7 +25,7 @@ sub new { || $meta->throw_error("You cannot augment '$name' because it has no super method", data => $name); my $_super_package = $super->package_name; - # BUT!,... if this is an overriden method .... + # BUT!,... if this is an overridden method .... if ($super->isa('Moose::Meta::Method::Overriden')) { # we need to be sure that we actually # find the next method, which is not diff --git a/lib/Moose/Meta/Method/Constructor.pm b/lib/Moose/Meta/Method/Constructor.pm index 2f6c2b5..48edeb7 100644 --- a/lib/Moose/Meta/Method/Constructor.pm +++ b/lib/Moose/Meta/Method/Constructor.pm @@ -409,7 +409,7 @@ Moose::Meta::Method::Constructor - Method Meta Object for constructors =head1 DESCRIPTION This is a subclass of L<Class::MOP::Method> which handles -constructing an approprate Constructor methods. This is primarily +constructing an appropriate Constructor methods. This is primarily used in the making of immutable metaclasses, otherwise it is not particularly useful. diff --git a/lib/Moose/Meta/Method/Delegation.pm b/lib/Moose/Meta/Method/Delegation.pm index a0fe9e3..451cb55 100644 --- a/lib/Moose/Meta/Method/Delegation.pm +++ b/lib/Moose/Meta/Method/Delegation.pm @@ -127,7 +127,7 @@ these options are: =item I<attribute> This must be an instance of C<Moose::Meta::Attribute> which this -accessor is being generated for. This paramter is B<required>. +accessor is being generated for. This parameter is B<required>. =item I<delegate_to_method> diff --git a/lib/Moose/Meta/Method/Destructor.pm b/lib/Moose/Meta/Method/Destructor.pm index ac547a0..40f1fcd 100644 --- a/lib/Moose/Meta/Method/Destructor.pm +++ b/lib/Moose/Meta/Method/Destructor.pm @@ -110,7 +110,7 @@ Moose::Meta::Method::Destructor - Method Meta Object for destructors =head1 DESCRIPTION This is a subclass of L<Class::MOP::Method> which handles -constructing an approprate Destructor method. This is primarily +constructing an appropriate Destructor method. This is primarily used in the making of immutable metaclasses, otherwise it is not particularly useful. diff --git a/lib/Moose/Meta/Method/Overriden.pm b/lib/Moose/Meta/Method/Overriden.pm index 1a56a27..31182cc 100644 --- a/lib/Moose/Meta/Method/Overriden.pm +++ b/lib/Moose/Meta/Method/Overriden.pm @@ -55,7 +55,7 @@ __END__ =head1 NAME -Moose::Meta::Method::Overriden - A Moose Method metaclass for overriden methods +Moose::Meta::Method::Overriden - A Moose Method metaclass for overridden methods =head1 DESCRIPTION diff --git a/lib/Moose/Meta/Role/Application/ToClass.pm b/lib/Moose/Meta/Role/Application/ToClass.pm index 43d1e23..5b5144e 100644 --- a/lib/Moose/Meta/Role/Application/ToClass.pm +++ b/lib/Moose/Meta/Role/Application/ToClass.pm @@ -108,7 +108,7 @@ sub apply_methods { next; } else { - # add it, although it could be overriden + # add it, although it could be overridden $class->add_method( $method_name, $role->get_method($method_name) diff --git a/lib/Moose/Meta/Role/Application/ToRole.pm b/lib/Moose/Meta/Role/Application/ToRole.pm index 13cd34e..6b7e811 100644 --- a/lib/Moose/Meta/Role/Application/ToRole.pm +++ b/lib/Moose/Meta/Role/Application/ToRole.pm @@ -100,7 +100,7 @@ sub apply_methods { $role2->add_required_methods($method_name); } else { - # add it, although it could be overriden + # add it, although it could be overridden $role2->add_method( $method_name, $role1->get_method($method_name) @@ -118,7 +118,7 @@ sub apply_override_method_modifiers { if ($role2->has_method($method_name)) { # if it is being composed into another role # we have a conflict here, because you cannot - # combine an overriden method with a locally + # combine an overridden method with a locally # defined one Moose->throw_error("Role '" . $role1->name . "' has encountered an 'override' method conflict " . "during composition (A local method of the same name as been found). This " . diff --git a/lib/Moose/Meta/TypeConstraint/Union.pm b/lib/Moose/Meta/TypeConstraint/Union.pm index c61d8bf..3986d1d 100644 --- a/lib/Moose/Meta/TypeConstraint/Union.pm +++ b/lib/Moose/Meta/TypeConstraint/Union.pm @@ -166,7 +166,7 @@ but it does provide the same API =back -=head2 Overriden methods +=head2 Overridden methods =over 4 diff --git a/lib/Moose/Object.pm b/lib/Moose/Object.pm index e61f935..46e821b 100644 --- a/lib/Moose/Object.pm +++ b/lib/Moose/Object.pm @@ -97,15 +97,6 @@ sub does { return 0; } -# RANT: -# Cmon, how many times have you written -# the following code while debugging: -# -# use Data::Dumper; -# warn Dumper \%thing; -# -# It can get seriously annoying, so why -# not just do this ... sub dump { my $self = shift; require Data::Dumper; @@ -173,7 +164,7 @@ C<DOES> is equivalent to C<isa> or C<does>. =item B<dump ($maxdepth)> -Cmon, how many times have you written the following code while debugging: +C'mon, how many times have you written the following code while debugging: use Data::Dumper; warn Dumper $obj; diff --git a/lib/Moose/Role.pm b/lib/Moose/Role.pm index d743c53..e1f2b9c 100644 --- a/lib/Moose/Role.pm +++ b/lib/Moose/Role.pm @@ -263,10 +263,10 @@ ordering. =item * The C<requires> keyword currently only works with actual methods. A method -modifier (before/around/after and override) will not count as a fufillment +modifier (before/around/after and override) will not count as a fulfillment of the requirement, and neither will an autogenerated accessor for an attribute. -It is likely that attribute accessors will eventually be allowed to fufill those +It is likely that attribute accessors will eventually be allowed to fulfill those requirements, or we will introduce a C<requires_attr> keyword of some kind instead. This decision has not yet been finalized. diff --git a/lib/Moose/Spec/Role.pod b/lib/Moose/Spec/Role.pod index 76e78fa..0d845da 100644 --- a/lib/Moose/Spec/Role.pod +++ b/lib/Moose/Spec/Role.pod @@ -44,17 +44,17 @@ the consuming role. =item Required Attributes Just as a role can require methods, it can also require attributes. -The requirement fufilling attribute must implement at least as much +The requirement fulfilling attribute must implement at least as much as is required. That means, for instance, that if the role requires -that the attribute be readonly, then it must at least have a reader +that the attribute be read-only, then it must at least have a reader and can also have a writer. It means that if the role requires that the attribute be an ArrayRef, then it must either be an ArrayRef or a subtype of an ArrayRef. -=item Overriden Methods +=item Overridden Methods The C<override> and C<super> keywords are allowed in roles, but -thier behavior is different from that of it's class counterparts. +their behavior is different from that of it's class counterparts. The C<super> in a class refers directly to that class's superclass, while the C<super> in a role is deferred and only has meaning once the role is composed into a class. Once that composition occurs, @@ -88,7 +88,7 @@ just like attributes and the C<override> keyword). =item Methods -=item Overriden methods +=item Overridden methods =item Method Modifiers (before, around, after) @@ -110,7 +110,7 @@ just like attributes and the C<override> keyword). =item Methods -=item Overriden methods +=item Overridden methods =item Method Modifiers (before, around, after) @@ -134,8 +134,8 @@ The product of the composition is a composite role =item Attributes Attributes with the same name will conflict and are considered -a un-recoverable error. No other aspect of the attribute is -examained, it is enough that just the attribute names conflict. +a unrecoverable error. No other aspect of the attribute is +examined, it is enough that just the attribute names conflict. The reason for such early and harsh conflicts with attributes is because there is so much room for variance between two @@ -162,17 +162,17 @@ conflicts. This can be illustrated like so: method set { a, b, d, e } conflict set { c } -=item Overriden methods +=item Overridden methods -An overriden method can conflict in one of two ways. +An overridden method can conflict in one of two ways. -The first way is with another overriden method of the same -name, and this is considered an un-recoverable error. This +The first way is with another overridden method of the same +name, and this is considered an unrecoverable error. This is an obvious error since you cannot override a method twice in the same class. -The second way for conflict is for an overriden method and a -regular method to have the same name. This is also an un-recoverable +The second way for conflict is for an overridden method and a +regular method to have the same name. This is also an unrecoverable error since there is no way to combine these two, nor is it okay for both items to be composed into a single class at some point. @@ -202,7 +202,7 @@ is the key. This is a just a set of complex edge cases which can easily get confused. This attempts to clarify those cases and provide an -explination of what is going on in them. +explanation of what is going on in them. =over 4 @@ -258,9 +258,9 @@ This works because the combination of Role::Foo and Role::Bar produce a conflict with the C<foo> method. This conflict results in the composite role (that was created by the combination of Role::Foo and Role::Bar using the I<with> keyword) having a method requirement -of C<foo>. The Role::FooBar then fufills this requirement. +of C<foo>. The Role::FooBar then fulfills this requirement. -It is important to note that Role::FooBar is simply fufilling the +It is important to note that Role::FooBar is simply fulfilling the required C<foo> method, and **NOT** overriding C<foo>. This is an important distinction to make. @@ -304,7 +304,7 @@ This is the main site for the original Traits papers. I created this implementation of traits several years ago, after reading the papers linked above. (This module is now -maintatined by Ovid and I am no longer involved with it). +maintained by Ovid and I am no longer involved with it). =back diff --git a/lib/Moose/Util.pm b/lib/Moose/Util.pm index 149587b..6edcd1d 100644 --- a/lib/Moose/Util.pm +++ b/lib/Moose/Util.pm @@ -213,7 +213,7 @@ This is a set of utility functions to help working with Moose classes, and is used internally by Moose itself. The goal is to provide useful functions that for both Moose users and Moose extenders (MooseX:: authors). -This is a relatively new addition to the Moose toolchest, so ideas, +This is a relatively new addition to the Moose tool chest, so ideas, suggestions and contributions to this collection are most welcome. See the L<TODO> section below for a list of ideas for possible functions to write. @@ -241,7 +241,7 @@ Given an C<$applicant> (which can somehow be turned into either a metaclass or a metarole) and a list of C<@roles> this will do the right thing to apply the C<@roles> to the C<$applicant>. This is actually used internally by both L<Moose> and L<Moose::Role>, and the -C<@roles> will be pre-processed through L<Data::OptList::mkopt> +C<@roles> will be preprocessed through L<Data::OptList::mkopt> to allow for the additional arguments to be passed. =item B<get_all_attribute_values($meta, $instance)> diff --git a/lib/Moose/Util/MetaRole.pm b/lib/Moose/Util/MetaRole.pm index c8053fd..0cb005e 100644 --- a/lib/Moose/Util/MetaRole.pm +++ b/lib/Moose/Util/MetaRole.pm @@ -225,24 +225,24 @@ error: =item 1. -There is a class (ClassA) which uses some extension(s) that apply +There is a class (C<ClassA>) which uses some extension(s) that apply roles to the metaclass. =item 2. -You have another class (ClassB) which wants to subclass ClassA and +You have another class (C<ClassB>) which wants to subclass C<ClassA> and apply some more extensions. =back Normally, the call to C<extends> will happen at run time, I<after> the additional extensions are applied. This causes an error when we try to -make the metaclass for ClassB compatible with the metaclass for -ClassA. +make the metaclass for C<ClassB> compatible with the metaclass for +C<ClassA>. We hope to be able to fix this in the future. -For now the workaround is for ClassB to make sure it extends ClassA +For now the workaround is for C<ClassB> to make sure it extends C<ClassA> I<before> it loads extensions: package ClassB; diff --git a/lib/Moose/Util/TypeConstraints.pm b/lib/Moose/Util/TypeConstraints.pm index 855bd00..0386070 100644 --- a/lib/Moose/Util/TypeConstraints.pm +++ b/lib/Moose/Util/TypeConstraints.pm @@ -702,7 +702,7 @@ Moose::Util::TypeConstraints - Type constraint system for Moose =head1 DESCRIPTION This module provides Moose with the ability to create custom type -contraints to be used in attribute definition. +constraints to be used in attribute definition. =head2 Important Caveat @@ -783,7 +783,7 @@ literally interpreted as a type name. B<NOTE:> The C<Undef> type constraint for the most part works correctly now, but edge cases may still exist, please use it -sparringly. +sparingly. B<NOTE:> The C<ClassName> type constraint does a complex package existence check. This means that your class B<must> be loaded for @@ -886,8 +886,8 @@ The resulting constraint will be a subtype of C<Str> and will match any of the items in C<@values>. It is case sensitive. See the L<SYNOPSIS> for a simple example. -B<NOTE:> This is not a true proper enum type, it is simple -a convient constraint builder. +B<NOTE:> This is not a true proper enum type, it is simply +a convenient constraint builder. =item B<enum (\@values)> @@ -926,7 +926,7 @@ exception thrown. This can be used to define a "hand optimized" version of your type constraint which can be used to avoid traversing a subtype -constraint heirarchy. +constraint hierarchy. B<NOTE:> You should only use this if you know what you are doing, all the built in types use this, so your subtypes (assuming they @@ -967,9 +967,9 @@ This is just sugar for the type coercion construction syntax. Given a string that is expected to match a type constraint, will normalize the string so that extra whitespace and newlines are removed. -=item B<create_type_constraint_union ($pipe_seperated_types | @type_constraint_names)> +=item B<create_type_constraint_union ($pipe_separated_types | @type_constraint_names)> -Given string with C<$pipe_seperated_types> or a list of C<@type_constraint_names>, +Given string with C<$pipe_separated_types> or a list of C<@type_constraint_names>, this will return a L<Moose::Meta::TypeConstraint::Union> instance. =item B<create_parameterized_type_constraint ($type_name)> diff --git a/lib/Moose/Util/TypeConstraints/OptimizedConstraints.pm b/lib/Moose/Util/TypeConstraints/OptimizedConstraints.pm index 8997d36..dd87ba4 100644 --- a/lib/Moose/Util/TypeConstraints/OptimizedConstraints.pm +++ b/lib/Moose/Util/TypeConstraints/OptimizedConstraints.pm @@ -85,35 +85,35 @@ no user serviceable parts inside. =over 4 -=item Value +=item C<Value> -=item Ref +=item C<Ref> -=item Str +=item C<Str> -=item Num +=item C<Num> -=item Int +=item C<Int> -=item ScalarRef +=item C<ScalarRef> -=item ArrayRef +=item C<ArrayRef> -=item HashRef +=item C<HashRef> -=item CodeRef +=item C<CodeRef> -=item RegexpRef +=item C<RegexpRef> -=item GlobRef +=item C<GlobRef> -=item FileHandle +=item C<FileHandle> -=item Object +=item C<Object> -=item Role +=item C<Role> -=item ClassName +=item C<ClassName> =back diff --git a/lib/oose.pm b/lib/oose.pm index e1c2a21..d6b4d3a 100644 --- a/lib/oose.pm +++ b/lib/oose.pm @@ -45,7 +45,7 @@ oose - syntactic sugar to make Moose one-liners easier oose.pm is a simple source filter that adds C<package $name; use Moose;> to the beginning of your script and was entirely created because typing -perl -e'package Foo; use Moose; ...' was annoying me. +C<perl -e'package Foo; use Moose; ...'> was annoying me. =head1 INTERFACE diff --git a/t/010_basics/005_override_augment_inner_super.t b/t/010_basics/005_override_augment_inner_super.t index 2d4a330..c81a506 100644 --- a/t/010_basics/005_override_augment_inner_super.t +++ b/t/010_basics/005_override_augment_inner_super.t @@ -56,7 +56,7 @@ Allow me to clarify this one now ... Since Baz::bar is an augment routine, it needs to find the correct inner() to be called by. In this case it is Foo::bar. -However, Bar::bar is inbetween us, so it should actually be +However, Bar::bar is in-between us, so it should actually be called first. Bar::bar is an overriden sub, and calls super() which in turn then calls our Foo::bar, which calls inner(), which calls Baz::bar. diff --git a/t/010_basics/011_moose_respects_type_constraints.t b/t/010_basics/011_moose_respects_type_constraints.t index a62f147..96058f4 100644 --- a/t/010_basics/011_moose_respects_type_constraints.t +++ b/t/010_basics/011_moose_respects_type_constraints.t @@ -11,7 +11,7 @@ use Moose::Util::TypeConstraints; =pod This tests demonstrates that Moose will not override -a pre-existing type constraint of the same name when +a preexisting type constraint of the same name when making constraints for a Moose-class. It also tests that an attribute which uses a 'Foo' for diff --git a/t/030_roles/005_role_conflict_detection.t b/t/030_roles/005_role_conflict_detection.t index 09a664e..b99b90f 100644 --- a/t/030_roles/005_role_conflict_detection.t +++ b/t/030_roles/005_role_conflict_detection.t @@ -3,7 +3,7 @@ use strict; use warnings; -use Test::More tests => 87; # it's really 124 with kolibre's tests; +use Test::More tests => 87; # it's really 124 with kolibrie's tests; use Test::Exception; =pod @@ -352,8 +352,7 @@ Role conflicts between attributes and methods [15:24] <kolibrie> when class 'has' method and role defines method, class wins [15:24] <kolibrie> when class defines method and role 'has' method, role wins [15:24] <kolibrie> when class 'has' method and role 'has' method, role wins -[15:24] <kolibrie> which means when class 'has' method and two roles 'has' method, no tiebreak is d -[15:24] <kolibrie> etected +[15:24] <kolibrie> which means when class 'has' method and two roles 'has' method, no tiebreak is detected [15:24] <perigrin> this is with role and has declaration in the exact same order in every case? [15:25] <kolibrie> yes [15:25] <perigrin> interesting diff --git a/t/030_roles/008_role_conflict_edge_cases.t b/t/030_roles/008_role_conflict_edge_cases.t index 12e4873..3ff06cd 100644 --- a/t/030_roles/008_role_conflict_edge_cases.t +++ b/t/030_roles/008_role_conflict_edge_cases.t @@ -8,7 +8,7 @@ use Test::Exception; =pod -Check for repeated inheritence causing +Check for repeated inheritance causing a method conflict (which is not really a conflict) @@ -47,7 +47,7 @@ is(My::Test::Class1->foo, 'Role::Base::foo', '... got the right value from metho =pod -Check for repeated inheritence causing +Check for repeated inheritance causing a method conflict with method modifiers (which is not really a conflict) @@ -97,7 +97,7 @@ is(My::Test::Class2->foo, 'My::Test::Class2::Base -> Role::Base::foo', '... got =pod -Check for repeated inheritence of the +Check for repeated inheritance of the same code. There are no conflicts with before/around/after method modifiers. @@ -150,7 +150,7 @@ is(My::Test::Class3->foo, 'Role::Base::foo(My::Test::Class3::Base)', '... got th =pod -Check for repeated inheritence causing +Check for repeated inheritance causing a attr conflict (which is not really a conflict) diff --git a/t/040_type_constraints/014_type_notation_parser.t b/t/040_type_constraints/014_type_notation_parser.t index 3487dc7..03d1d76 100644 --- a/t/040_type_constraints/014_type_notation_parser.t +++ b/t/040_type_constraints/014_type_notation_parser.t @@ -11,7 +11,7 @@ BEGIN { =pod -This is a good canidate for LectroTest +This is a good candidate for LectroTest Volunteers welcome :) =cut diff --git a/t/100_bugs/009_augment_recursion_bug.t b/t/100_bugs/009_augment_recursion_bug.t index 3e41104..11cd728 100644 --- a/t/100_bugs/009_augment_recursion_bug.t +++ b/t/100_bugs/009_augment_recursion_bug.t @@ -38,7 +38,7 @@ isa_ok($baz, 'Foo'); When a subclass which augments foo(), calls a subclass which does not augment foo(), there is a chance for some confusion. If Moose does not realize that -Bar does not augment foo(), becuase it is in the call flow of Baz which does, +Bar does not augment foo(), because it is in the call flow of Baz which does, then we may have an infinite loop. =cut diff --git a/t/200_examples/006_example_Protomoose.t b/t/200_examples/006_example_Protomoose.t index b1e3f2a..6719e57 100644 --- a/t/200_examples/006_example_Protomoose.t +++ b/t/200_examples/006_example_Protomoose.t @@ -41,9 +41,9 @@ Well cause merlyn asked if it could :) # the correct instance in the accessors sub find_instance { - my ($self, $canidate, $accessor_type) = @_; + my ($self, $candidate, $accessor_type) = @_; - my $instance = $canidate; + my $instance = $candidate; my $attr = $self->associated_attribute; # if it is a class calling it ...