about C<alias> and C<excludes>).
Because roles serve many different masters, they usually provide only the least
-common denominator of functionality. Not all consumers of a role have a C<>.
-Thus, more configurability than C<alias> and C<excludes> is required. Perhaps
-your role needs to know which method to call when it is done. Or what default
-value to use for its url attribute.
+common denominator of functionality. To empower roles further, more
+configurability than C<alias> and C<excludes> is required. Perhaps your role
+needs to know which method to call when it is done. Or what default value to
+use for its url attribute.
Parameterized roles offer exactly this solution.
=head3 C<role>
C<role> takes a block of code that will be used to generate your role with its
-parameters bound. Here is where you put your regular role code: use C<has>,
-method modifiers, and so on. You receive as an argument the parameter object
-constructed by C<with>. You can access the parameters just like regular
+parameters bound. Here is where you declare parameterized components: use
+C<has>, method modifiers, and so on. You receive as an argument the parameter
+object constructed by C<with>. You can access the parameters just like regular
attributes on that object (assuming you declared them readable).
Each time you compose this parameterized role, the role {} block will be
role.
Due to limitations inherent in Perl, you must declare methods with
-C<method name => sub { ... }> instead of the usual C<sub name { ... }>. Your
-methods may, of course, close over the parameter object. This means that your
-methods may use parameters however they wish!
+C<< method name => sub { ... } >> instead of the usual C<sub name { ... }>.
+Your methods may, of course, close over the parameter object. This means that
+your methods may use parameters however they wish!
=head1 IMPLEMENTATION NOTES