assert_valid to use constraints for assertion

[gitmo/Moose.git] / lib / Moose / Manual / Roles.pod

diff --git a/lib/Moose/Manual/Roles.pod b/lib/Moose/Manual/Roles.pod
index b1e45b7..88d94d8 100644 (file)
--- a/lib/Moose/Manual/Roles.pod
+++ b/lib/Moose/Manual/Roles.pod
@@ -153,8 +153,8 @@ set to true when C<break> is called.
 If you are familiar with the concept of abstract base classes in other
 languages, you may be tempted to use roles in the same way.
 
-You I<can> define a "interface-only" role, one that contains I<just> a
-list of required methods.
+You I<can> define an "interface-only" role, one that contains I<just>
+a list of required methods.
 
 However, any class which consumes this role must implement all of the
 required methods, either directly or through inheritance from a
@@ -196,7 +196,7 @@ If a class composes multiple roles, and those roles have methods of
 the same name, we will have a conflict. In that case, the composing
 class is required to provide its I<own> method of the same name.
 
-  package Breakdances;
+  package Breakdancer;
 
   use Moose::Role
 
@@ -231,15 +231,15 @@ However, aliasing a method simply makes a I<copy> of the method with
 the new name. We also need to exclude the original name:
 
   with 'Breakable' => {
-      alias   => { break => 'break_bone' },
-      exclude => 'break',
+      alias    => { break => 'break_bone' },
+      excludes => 'break',
       },
       'Breakdancer' => {
-      alias   => { break => 'break_dance' },
-      exclude => 'break',
+      alias    => { break => 'break_dance' },
+      excludes => 'break',
       };
 
-The exclude parameter prevents the C<break> method from being composed
+The excludes parameter prevents the C<break> method from being composed
 into the C<FragileDancer> class, so we don't have a conflict. This
 means that C<FragileDancer> does not need to implement its own
 C<break> method.