}
}
-sub role {
+sub role (&) {
my $caller = shift;
my $role_generator = shift;
Class::MOP::Class->initialize($caller)->role_generator($role_generator);
);
}
-# give role a (&) prototype
-moose_around _make_wrapper => sub {
- my $orig = shift;
- my ($self, $caller, $sub, $fq_name) = @_;
-
- if ($fq_name =~ /::role$/) {
- return sub (&) { $sub->($caller, @_) };
- }
-
- return $orig->(@_);
-};
-
sub has {
my $caller = shift;
my $meta = $CURRENT_METACLASS || Class::MOP::Class->initialize($caller);
=head1 DESCRIPTION
-Your parameterized role consists of two things: parameter declarations and a
-C<role> block.
+Your parameterized role consists of two new things: parameter declarations
+and a C<role> block.
Parameters are declared using the L</parameter> keyword which very much
resembles L<Moose/has>. You can use any option that L<Moose/has> accepts. The
-default value for the "is" option is "ro" as that's a very common case. These
+default value for the C<is> option is C<ro> as that's a very common case. These
parameters will get their values when the consuming class (or role) uses
L<Moose/with>. A parameter object will be constructed with these values, and
passed to the C<role> block.
The C<role> block then uses the usual L<Moose::Role> keywords to build up a
role. You can shift off the parameter object to inspect what the consuming
-class provided as parameters. You can use the parameters to make your role
-customizable!
+class provided as parameters. You use the parameters to customize your
+role however you wish.
+
+There are many possible implementations for parameterized roles (hopefully with
+a consistent enough API); I believe this to be the easiest and most flexible
+design. Coincidentally, Pugs originally had an eerily similar design.
-There are many paths to parameterized roles (hopefully with a consistent enough
-API); I believe this to be the easiest and most flexible implementation.
-Coincidentally, Pugs has a very similar design (I'm not yet convinced that that
-is a good thing).
+=head2 Why a parameters object?
+
+I've been asked several times "Why use a parameter I<object> and not just a
+parameter I<hashref>? That would eliminate the need to explicitly declare your
+parameters."
+
+The benefits of using an object are similar to the benefits of using Moose. You
+get an easy way to specify lazy defaults, type constraint, delegation, and so
+on. You get to use MooseX modules.
+
+You also get the usual introspective and intercessory abilities that come
+standard with the metaobject protocol. Ambitious users should be able to add
+traits to the parameters metaclass to further customize behavior. Please let
+me know if you're doing anything viciously complicated with this extension. :)
=head1 CAVEATS
L<Moose::Role/alias> and L<Moose::Role/excludes> are not yet supported. I'm
completely unsure of whether they should be handled by this module. Until we
-figure out a plan, both declaring and providing a parameter named C<alias> or
+figure out a plan, either declaring or providing a parameter named C<alias> or
C<excludes> is an error.
=head1 AUTHOR
=item L<MooseX::Role::Matcher>
-=item L<MooseX::Role::RelatedClassRoles>
-
=item L<MooseX::Role::XMLRPC::Client>
+=item L<MooseX::RelatedClassRoles>
+
=item L<WWW::Mechanize::TreeBuilder>
=item L<TAEB::Action::Role::Item>