Moose::Role:

* minor POD cleanup.

diff --git a/lib/Moose/Role.pm b/lib/Moose/Role.pm
index 49810c5..2e6b187 100644 (file)
--- a/lib/Moose/Role.pm
+++ b/lib/Moose/Role.pm
@@ -185,9 +185,7 @@ Moose::Role - The Moose Role
 =head1 SYNOPSIS
 
   package Eq;
-  use strict;
-  use warnings;
-  use Moose::Role;
+  use Moose::Role; # automatically turns on strict and warnings
   
   requires 'equal';
   
@@ -199,9 +197,7 @@ Moose::Role - The Moose Role
   # ... then in your classes
   
   package Currency;
-  use strict;
-  use warnings;
-  use Moose;
+  use Moose; # automatically turns on strict and warnings
   
   with 'Eq';
   
@@ -212,61 +208,61 @@ Moose::Role - The Moose Role
 
 =head1 DESCRIPTION
 
-Role support in Moose is pretty solid at this point. However, the best 
-documentation is still the the test suite. It is fairly safe to assume 
-Perl 6 style behavior and then either refer to the test suite, or ask 
-questions on #moose if something doesn't quite do what you expect.
+Role support in Moose is pretty solid at this point. However, the best
+documentation is still the the test suite. It is fairly safe to assume Perl 6
+style behavior and then either refer to the test suite, or ask questions on
+#moose if something doesn't quite do what you expect.
 
-We are planning writing some more documentation in the near future, but
-nothing is ready yet, sorry.
+We are planning writing some more documentation in the near future, but nothing
+is ready yet, sorry.
 
 =head1 EXPORTED FUNCTIONS
 
-Currently Moose::Role supports all of the functions that L<Moose> exports, 
-but differs slightly in how some items are handled (see L<CAVEATS> below 
-for details). 
+Moose::Role currently supports all of the functions that L<Moose> exports, but
+differs slightly in how some items are handled (see L<CAVEATS> below for
+details).
 
-Moose::Role also offers two role specific keyword exports:
+Moose::Role also offers two role-specific keyword exports:
 
 =over 4
 
 =item B<requires (@method_names)>
 
 Roles can require that certain methods are implemented by any class which 
-C<does> the role. 
+C<does> the role.
 
 =item B<excludes (@role_names)>
 
 Roles can C<exclude> other roles, in effect saying "I can never be combined
 with these C<@role_names>". This is a feature which should not be used 
-lightly. 
+lightly.
 
 =back
 
 =head1 CAVEATS
 
-The role support now has only a few caveats. They are as follows:
+Role support has only a few caveats:
 
 =over 4
 
 =item *
 
-Roles cannot use the C<extends> keyword, it will throw an exception for now. 
+Roles cannot use the C<extends> keyword; it will throw an exception for now. 
 The same is true of the C<augment> and C<inner> keywords (not sure those 
 really make sense for roles). All other Moose keywords will be I<deferred> 
-so that they can be applied to the consuming class. 
+so that they can be applied to the consuming class.
 
 =item * 
 
-Role composition does it's best to B<not> be order sensitive when it comes
-to conflict resolution and requirements detection. However, it is order 
-sensitive when it comes to method modifiers. All before/around/after modifiers
-are included whenever a role is composed into a class, and then are applied 
-in the order the roles are used. This too means that there is no conflict for 
-before/around/after modifiers as well. 
+Role composition does its best to B<not> be order-sensitive when it comes to
+conflict resolution and requirements detection. However, it is order-sensitive
+when it comes to method modifiers. All before/around/after modifiers are
+included whenever a role is composed into a class, and then applied in the order
+in which the roles are used. This also means that there is no conflict for
+before/around/after modifiers.
 
-In most cases, this will be a non issue, however it is something to keep in 
-mind when using method modifiers in a role. You should never assume any 
+In most cases, this will be a non-issue; however, it is something to keep in
+mind when using method modifiers in a role. You should never assume any
 ordering.
 
 =item *
@@ -275,9 +271,9 @@ The C<requires> keyword currently only works with actual methods. A method
 modifier (before/around/after and override) will not count as a fufillment 
 of the requirement, and neither will an autogenerated accessor for an attribute.
 
-It is likely that the attribute accessors will eventually be allowed to fufill 
-those requirements, either that or we will introduce a C<requires_attr> keyword
-of some kind instead. This descision has not yet been finalized.
+It is likely that attribute accessors will eventually be allowed to fufill those
+requirements, or we will introduce a C<requires_attr> keyword of some kind
+instead. This decision has not yet been finalized.
 
 =back