Moose::Role(3pm)               User Contributed Perl Documentation               Moose::Role(3pm)



NAME
       Moose::Role - The Moose Role

VERSION
       version 2.1213

SYNOPSIS
         package Eq;
         use Moose::Role; # automatically turns on strict and warnings

         requires 'equal';

         sub no_equal {
             my ($self, $other) = @_;
             !$self->equal($other);
         }

         # ... then in your classes

         package Currency;
         use Moose; # automatically turns on strict and warnings

         with 'Eq';

         sub equal {
             my ($self, $other) = @_;
             $self->as_float == $other->as_float;
         }

         # ... and also

         package Comparator;
         use Moose;

         has compare_to => (
             is      => 'ro',
             does    => 'Eq',
             handles => 'Eq',
         );

         # ... which allows

         my $currency1 = Currency->new(...);
         my $currency2 = Currency->new(...);
         Comparator->new(compare_to => $currency1)->equal($currency2);

DESCRIPTION
       The concept of roles is documented in Moose::Manual::Roles. This document serves as API
       documentation.

EXPORTED FUNCTIONS
       Moose::Role currently supports all of the functions that Moose exports, but differs
       slightly in how some items are handled (see "CAVEATS" below for details).

       Moose::Role also offers two role-specific keyword exports:

       requires (@method_names)
           Roles can require that certain methods are implemented by any class which "does" the
           role.

           Note that attribute accessors also count as methods for the purposes of satisfying the
           requirements of a role.

       excludes (@role_names)
           Roles can "exclude" other roles, in effect saying "I can never be combined with these
           @role_names". This is a feature which should not be used lightly.

   unimport
       Moose::Role offers a way to remove the keywords it exports, through the "unimport" method.
       You simply have to say "no Moose::Role" at the bottom of your code for this to work.

METACLASS
       When you use Moose::Role, you can specify traits which will be applied to your role
       metaclass:

           use Moose::Role -traits => 'My::Trait';

       This is very similar to the attribute traits feature. When you do this, your class's
       "meta" object will have the specified traits applied to it. See "Metaclass and Trait Name
       Resolution" in Moose for more details.

       All role metaclasses (note, not the role itself) extend Moose::Meta::Role.  You can test
       if a package is a role or not using "is_role" in Moose::Util.

APPLYING ROLES
       In addition to being applied to a class using the 'with' syntax (see Moose::Manual::Roles)
       and using the Moose::Util 'apply_all_roles' method, roles may also be applied to an
       instance of a class using Moose::Util 'apply_all_roles' or the role's metaclass:

          MyApp::Test::SomeRole->meta->apply( $instance );

       Doing this creates a new, mutable, anonymous subclass, applies the role to that, and
       reblesses. In a debugger, for example, you will see class names of the form "
       Moose::Meta::Class::__ANON__::SERIAL::6 ", which means that doing a 'ref' on your instance
       may not return what you expect. See Moose::Object for 'DOES'.

       Additional params may be added to the new instance by providing 'rebless_params'. See
       Moose::Meta::Role::Application::ToInstance.

CAVEATS
       Role support has only a few caveats:

       ·   Roles cannot use the "extends" keyword; it will throw an exception for now.  The same
           is true of the "augment" and "inner" keywords (not sure those really make sense for
           roles). All other Moose keywords will be deferred so that they can be applied to the
           consuming class.

       ·   Role composition does its best to 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 ordering.

BUGS
       See "BUGS" in Moose for details on reporting bugs.

AUTHORS
       ·   Stevan Little <stevan.little AT iinteractive.com>

       ·   Dave Rolsky <autarch AT urth.org>

       ·   Jesse Luehrs <doy AT tozt.net>

       ·   Shawn M Moore <code AT sartak.org>

       ·   XXXX XXX'XX (Yuval Kogman) <nothingmuch AT woobling.org>

       ·   Karen Etheridge <ether AT cpan.org>

       ·   Florian Ragwitz <rafl AT debian.org>

       ·   Hans Dieter Pearcey <hdp AT weftsoar.net>

       ·   Chris Prather <chris AT prather.org>

       ·   Matt S Trout <mst AT shadowcat.uk>

COPYRIGHT AND LICENSE
       This software is copyright (c) 2006 by Infinity Interactive, Inc..

       This is free software; you can redistribute it and/or modify it under the same terms as
       the Perl 5 programming language system itself.



perl v5.20.1                                2014-09-25                           Moose::Role(3pm)