Linux Certif

Toute la documentation sur la certification Linux LPI

MooseX::Role::Parameterized.3pm

NAME

MooseX::Role::Parameterized - parameterized roles

VERSION

version 0.06

SYNOPSIS

     package MyRole::Counter;
     use MooseX::Role::Parameterized;
 
     parameter name => (
         isa      => 'Str',
         required => 1,
     );
 
     role {
         my $p = shift;
 
         my $name = $p->name;
 
         has $name => (
             is      => 'rw',
             isa     => 'Int',
             default => 0,
         );
 
         method "increment_$name" => sub {
             my $self = shift;
             $self->$name($self->$name + 1);
         };
 
         method "decrement_$name" => sub {
             my $self = shift;
             $self->$name($self->$name - 1);
         };
     };
 
     package MyGame::Tile;
     use Moose;
 
     with 'MyRole::Counter' => { name => 'stepped_on' };
 
 

MooseX::Role::Parameterized::Tutorial

Stop! If you're new here, please read MooseX::Role::Parameterized::Tutorial for a much gentler introduction.

DESCRIPTION

Your parameterized role consists of two new things: parameter declarations and a "role" block.

Parameters are declared using the ``parameter'' keyword which very much resembles ``has'' in Moose. You can use any option that ``has'' in Moose accepts. The default value for the "is" option is "ro" as that's a very common case. These parameters will get their values when the consuming class (or role) uses ``with'' in Moose. A parameter object will be constructed with these values, and passed to the "role" block.

The "role" block then uses the usual 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 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.

Why a parameters object?

I've been asked several times "Why use a parameter object and not just a parameter 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. :)

CAVEATS

You must use this syntax to declare methods in the role block: "method NAME => sub { ... };". This is due to a limitation in Perl. In return though you can use parameters in your methods!

``alias'' in Moose::Role and ``excludes'' in Moose::Role are not yet supported. I'm completely unsure of whether they should be handled by this module. Until we figure out a plan, either declaring or providing a parameter named "alias" or "excludes" is an error.

AUTHOR

Shawn M Moore, "<sartak@bestpractical.com>"

EXAMPLES

MooseX::Role::Matcher

MooseX::Role::XMLRPC::Client

MooseX::RelatedClassRoles

WWW::Mechanize::TreeBuilder

NetHack::Item::Role::IncorporatesStats

TAEB::Action::Role::Item

KiokuDB::Role::Scan

Fey::Role::MakesAliasObjects

Fey::Role::HasAliasName

Fey::Role::SetOperation