[Moose-commits] r7524 - Moose/trunk/lib/Moose/Manual
hanekomu at code2.0beta.co.uk
hanekomu at code2.0beta.co.uk
Tue Feb 3 23:56:59 GMT 2009
Author: hanekomu
Date: 2009-02-03 15:56:59 -0800 (Tue, 03 Feb 2009)
New Revision: 7524
Modified:
Moose/trunk/lib/Moose/Manual/Attributes.pod
Moose/trunk/lib/Moose/Manual/BestPractices.pod
Moose/trunk/lib/Moose/Manual/Construction.pod
Moose/trunk/lib/Moose/Manual/MooseX.pod
Moose/trunk/lib/Moose/Manual/Roles.pod
Moose/trunk/lib/Moose/Manual/Types.pod
Log:
typo and style fixes for Moose::Manual documents
Modified: Moose/trunk/lib/Moose/Manual/Attributes.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/Attributes.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/Attributes.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -303,7 +303,7 @@
predicate => 'has_size',
);
-If your attribute name starts with an underscore (_), then the clearer
+If your attribute name starts with an underscore (C<_>), then the clearer
and predicate will as well:
has '_size' => (
@@ -351,7 +351,7 @@
init_arg => 'size',
);
-Now we have an attribute named bigness, but we pass C<size> to the
+Now we have an attribute named "bigness", but we pass C<size> to the
constructor.
Even more useful is the ability to disable setting an attribute via
@@ -411,7 +411,7 @@
isa => 'Str',
);
-This says that the first_name attribute must be a string.
+This says that the C<first_name> attribute must be a string.
Moose also provides a shortcut for specifying that an attribute only
accepts objects that do a certain role:
@@ -426,7 +426,7 @@
=head2 Delegation
-Attributes can define methods which simple delegate to their values:
+Attributes can define methods which simply delegate to their values:
has 'hair_color' => (
is => 'rw',
@@ -458,7 +458,7 @@
);
In this case, the metaclass C<Collection::Hash> really refers to
-C<MooseX::AttributeHelpers::Collection::Hash>.
+L<MooseX::AttributeHelpers::Collection::Hash>.
You can also apply one or more traits to an attribute:
@@ -514,7 +514,7 @@
=back
To override an attribute, you simply prepend its name with a plus sign
-(+):
+(C<+>):
package LazyPerson;
@@ -567,9 +567,9 @@
my %map = $object->mapping;
This option only works if your attribute is explicitly typed as an
-ArrayRef or HashRef.
+C<ArrayRef> or C<HashRef>.
-However, we recommend that you use C<MooseX::AttributeHelpers> for
+However, we recommend that you use L<MooseX::AttributeHelpers> for
these types of attributes, which gives you much more control over how
they are accessed and manipulated.
@@ -579,7 +579,7 @@
similar to C<builder>, except that it is I<only> called during object
construction.
-This option is inherited from C<Class::MOP>, but we recommend that you
+This option is inherited from L<Class::MOP>, but we recommend that you
use a C<builder> (which is Moose-only) instead.
=head1 AUTHOR
Modified: Moose/trunk/lib/Moose/Manual/BestPractices.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/BestPractices.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/BestPractices.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -32,7 +32,7 @@
1;
-The "no Moose" bit is simply good code hygiene, and making classes
+The C<no Moose> bit is simply good code hygiene, and making classes
immutable speeds up a lot of things, most notably object construction.
=head2 Always call SUPER::BUILDARGS
@@ -45,11 +45,11 @@
list and hashref of named parameters correctly, and also checks for a
I<non-hashref> single argument.
-=head2 Don't Use the initializer Feature
+=head2 Don't Use the C<initializer> Feature
Don't know what we're talking about? That's fine.
-=head2 Use builder Instead of default Most of the Time.
+=head2 Use C<builder> Instead of C<default> Most of the Time.
Builders can be inherited, they have explicit names, and they're just
plain cleaner.
@@ -59,14 +59,14 @@
Also, keep your builder methods private.
-=head2 Use lazy_build
+=head2 Use C<lazy_build>
Lazy is good, and often solves initialization ordering problems. It's
also good for deferring work that may never have to be done. If you're
going to be lazy, use I<lazy_build> to save yourself some typing and
standardize names.
-=head2 Consider Keeping clearers & predicates Private
+=head2 Consider Keeping Clearers and Predicates Private
Does everyone I<really> need to be able to clear an attribute?
Probably not. Don't expose this functionality outside your class
@@ -75,7 +75,7 @@
Predicates are less problematic, but there's no reason to make your
public API bigger than it has to be.
-=head2 Default to read-only, and Consider Keeping writers Private
+=head2 Default to read-only, and Consider Keeping Writers Private
Making attributes mutable just means more complexity to account for in
your program. The alternative to mutable state is to encourage users
@@ -91,11 +91,11 @@
itself, at least make sure that it has the same interface as the type
of object in the parent class.
-=head2 Use MooseX::AttributeHelpers Instead of auto_deref
+=head2 Use L<MooseX::AttributeHelpers> Instead of C<auto_deref>
The C<auto_deref> feature is a bit troublesome. Directly exposing a
complex attribute is ugly. Instead, consider using
-C<MooseX::AttributeHelpers> to define an API that exposes those pieces
+L<MooseX::AttributeHelpers> to define an API that exposes those pieces
of functionality that need exposing. Then you can expose just the
functionality that you want.
Modified: Moose/trunk/lib/Moose/Manual/Construction.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/Construction.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/Construction.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -9,7 +9,7 @@
B<You do not need to define a C<new()> method for your classes!>
When you C<use Moose> in your class, you will become a subclass of
-C<Moose::Object>, which provides a C<new> method for you. If you
+L<Moose::Object>, which provides a C<new> method for you. If you
follow our recommendations in L<Moose::Manual::BestPractices> and make
your class immutable, then you actually get a class-specific C<new>
method "inlined" in your class.
@@ -62,7 +62,7 @@
}
Note the call to C<SUPER::BUILDARGS>. This will call the default
-C<BUILDARGS> in C<Moose::Object>. This method handles distinguishing
+C<BUILDARGS> in L<Moose::Object>. This method handles distinguishing
between a hash reference and a plain hash for you.
=head2 BUILD
Modified: Moose/trunk/lib/Moose/Manual/MooseX.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/MooseX.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/MooseX.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -52,7 +52,7 @@
=head1 MooseX::StrictConstructor
By default, Moose lets you pass any old junk into a class's
-constructor. If you load C<MooseX::StrictConstructor>, your class will
+constructor. If you load L<MooseX::StrictConstructor>, your class will
throw an error if it sees something it doesn't recognize;
package User;
@@ -65,15 +65,15 @@
User->new( name => 'Bob', emali => 'bob at example.com' );
-With C<MooseX::StrictConstructor>, that typo ("emali") will cause a
+With L<MooseX::StrictConstructor>, that typo ("emali") will cause a
runtime error. With plain old Moose, the "emali" attribute would be
silently ignored.
=head1 MooseX::Params::Validate
-We have high hopes for the future of C<MooseX::Method::Signatures> and
-C<MooseX::Declare>. However, for now we recommend the decidedly more
-clunky (but also faster and simpler) C<MooseX::Params::Validate>. This
+We have high hopes for the future of L<MooseX::Method::Signatures> and
+L<MooseX::Declare>. However, for now we recommend the decidedly more
+clunky (but also faster and simpler) L<MooseX::Params::Validate>. This
module lets you apply Moose types and coercions to any method
arguments.
@@ -131,7 +131,7 @@
=head1 MooseX::Singleton
To be honest, using a singleton is often a hack, but it sure is a
-handy hack. C<MooseX::Singleton> lets you have a Moose class that's a
+handy hack. L<MooseX::Singleton> lets you have a Moose class that's a
singleton:
package Config;
@@ -180,7 +180,7 @@
=head2 MooseX::Types::Structured
-This extension builds on top of C<MooseX::Types> to let you declare
+This extension builds on top of L<MooseX::Types> to let you declare
complex data structure types.
use MooseX::Types -declare => [ qw( Name Color ) ];
Modified: Moose/trunk/lib/Moose/Manual/Roles.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/Roles.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/Roles.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -47,7 +47,7 @@
$self->is_broken(1);
}
-Except for our use of C<Moose::Role>, this looks just like a class
+Except for our use of L<Moose::Role>, this looks just like a class
definition with Moose. However, this is not a class, and it cannot be
instantiated.
Modified: Moose/trunk/lib/Moose/Manual/Types.pod
===================================================================
--- Moose/trunk/lib/Moose/Manual/Types.pod 2009-02-03 23:46:17 UTC (rev 7523)
+++ Moose/trunk/lib/Moose/Manual/Types.pod 2009-02-03 23:56:59 UTC (rev 7524)
@@ -118,7 +118,7 @@
isa => 'ArrayRef[DateTime]',
);
-Moose will assume that "DateTime" is a class name in both of these
+Moose will assume that C<DateTime> is a class name in both of these
instances.
=head1 SUBTYPES
@@ -128,7 +128,7 @@
A subtype is defined in terms of a parent type and a constraint. Any
constraints defined by the parent(s) will be checked first, and then
-the the subtype's . A value must pass I<all> of these checks to be
+the the subtype's. A value must pass I<all> of these checks to be
valid for the subtype.
Typically, a subtype takes the parent's constraint and makes it more
@@ -185,7 +185,7 @@
period, makes it clear that "MyApp::User" is a class and
"MyApp.Type.PositiveInt" is a Moose type defined by your application.
-The C<MooseX::Types> module lets you create bareword aliases to longer
+The L<MooseX::Types> module lets you create bareword aliases to longer
names and also automatically namespaces all the types you define.
=head1 COERCION
@@ -366,7 +366,7 @@
parameters. However, there are several MooseX extensions on CPAN which
let you do this.
-The simplest and least sugary is C<MooseX::Params::Validate>. This
+The simplest and least sugary is L<MooseX::Params::Validate>. This
lets you validate a set of named parameters using Moose types:
use Moose;
@@ -381,11 +381,11 @@
...
}
-C<MooseX::Params::Validate> also supports coercions.
+L<MooseX::Params::Validate> also supports coercions.
There are several more powerful extensions that support method
parameter validation using Moose types, including
-C<MooseX::Method::Signatures>, which gives you a full-blown C<method>
+L<MooseX::Method::Signatures>, which gives you a full-blown C<method>
keyword.
method morning (Str $name) {
More information about the Moose-commits
mailing list