From: Dave Rolsky <autarch@urth.org>
Date: Sat, 14 Feb 2009 17:47:01 +0000 (+0000)
Subject: Be consistent and say "attribute option(s)", not "parameter(s)"
X-Git-Tag: 0.70~7
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=16fb3624a621bb2e0bb2969cedaba080ae6a44f7;p=gitmo%2FMoose.git

Be consistent and say "attribute option(s)", not "parameter(s)"
---

diff --git a/lib/Moose.pm b/lib/Moose.pm
index 81b1df0..b7a9d71 100644
--- a/lib/Moose.pm
+++ b/lib/Moose.pm
@@ -884,7 +884,7 @@ specified by C<for_class>. This method injects a a C<meta> accessor
 into the class so you can get at this object. It also sets the class's
 superclass to C<base_class>, with L<Moose::Object> as the default.
 
-You can specify an alternate metaclass with the C<metaclass> parameter.
+You can specify an alternate metaclass with the C<metaclass> option.
 
 For more detail on this topic, see L<Moose::Cookbook::Extending::Recipe2>.
 
diff --git a/lib/Moose/Cookbook/Basics/Recipe4.pod b/lib/Moose/Cookbook/Basics/Recipe4.pod
index 2da9616..f6748f7 100644
--- a/lib/Moose/Cookbook/Basics/Recipe4.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe4.pod
@@ -104,7 +104,7 @@ In the recipe we also make use of L<Locale::US> and L<Regexp::Common>
 to build constraints, showing how how constraints can make use of
 existing CPAN tools for data validation.
 
-Finally, we introduce the C<required> attribute parameter.
+Finally, we introduce the C<required> attribute option.
 
 The the C<Address> class we define two subtypes. The first uses the
 L<Locale::US> module to check the validity of a state. It accepts
@@ -159,11 +159,11 @@ A company also needs a name:
 
   has 'name' => ( is => 'rw', isa => 'Str', required => 1 );
 
-This introduces a new attribute parameter, C<required>. If an
-attribute is required, then it must be passed to the class's
-constructor, or an exception will be thrown. It's important to
-understand that a C<required> attribute can still be false or
-C<undef>, if its type constraint allows that.
+This introduces a new attribute option, C<required>. If an attribute
+is required, then it must be passed to the class's constructor, or an
+exception will be thrown. It's important to understand that a
+C<required> attribute can still be false or C<undef>, if its type
+constraint allows that.
 
 The next attribute, C<employees>, uses a I<parameterized> type
 constraint:
diff --git a/lib/Moose/Cookbook/Basics/Recipe5.pod b/lib/Moose/Cookbook/Basics/Recipe5.pod
index a16f60d..9b74d3e 100644
--- a/lib/Moose/Cookbook/Basics/Recipe5.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe5.pod
@@ -57,7 +57,7 @@ another.
 
 This is very powerful, but it's also magical, so you have to
 explicitly ask for an attribute to be coerced. To do this, you must
-set the C<coerce> attribute parameter to a true value.
+set the C<coerce> attribute option to a true value.
 
 First, we create the subtype to which we will coerce the other types:
 
diff --git a/lib/Moose/Cookbook/Basics/Recipe9.pod b/lib/Moose/Cookbook/Basics/Recipe9.pod
index f087103..fd82341 100644
--- a/lib/Moose/Cookbook/Basics/Recipe9.pod
+++ b/lib/Moose/Cookbook/Basics/Recipe9.pod
@@ -74,8 +74,8 @@ L<Moose::Manual::Attributes> for more details.
 
 =head2 The lazy_build shortcut
 
-The C<lazy_build> attribute parameter can be used as sugar to specify
-a whole set of attribute parameters at once:
+The C<lazy_build> attribute option can be used as sugar to specify
+a whole set of attribute options at once:
 
   has 'animal' => (
       is         => 'ro',
diff --git a/lib/Moose/Cookbook/Extending/Recipe1.pod b/lib/Moose/Cookbook/Extending/Recipe1.pod
index 4449ebd..89c5c18 100644
--- a/lib/Moose/Cookbook/Extending/Recipe1.pod
+++ b/lib/Moose/Cookbook/Extending/Recipe1.pod
@@ -158,8 +158,8 @@ class.
 
 Moose does not provide any simple APIs for consumers to use a subclass
 extension, except for attribute metaclasses. The attribute declaration
-parameters include a C<metaclass> parameter a consumer of your
-extension can use to specify your subclass.
+options include a C<metaclass> option a consumer of your extension can
+use to specify your subclass.
 
 This is one reason why implementing an extension as a subclass can be
 a poor choice. However, you can force the use of certain subclasses at
diff --git a/lib/Moose/Manual/Types.pod b/lib/Moose/Manual/Types.pod
index 17ae54b..9a17ea6 100644
--- a/lib/Moose/Manual/Types.pod
+++ b/lib/Moose/Manual/Types.pod
@@ -208,7 +208,7 @@ works.
 Coercions, like type names, are global. This is I<another> reason why
 it is good to namespace your types. Moose will I<never> try to coerce
 a value unless you explicitly ask for it. This is done by setting the
-C<coerce> attribute parameter to a true value:
+C<coerce> attribute option to a true value:
 
   package Foo;
 
@@ -351,7 +351,7 @@ This creates a type named C<RGB>
 
 All of the type creation functions return a type object. This type
 object can be used wherever you would use a type name, as a parent
-type, or as the value for an attribute's C<isa> parameter:
+type, or as the value for an attribute's C<isa> option:
 
   has 'size' => (
       is => 'rw',