Moose::Role man page on Kali

Man page or keyword search:  
man Server   9211 pages
apropos Keyword Search (all sections)
Output format
Kali logo
[printable version]

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

NAME
       Moose::Role - The Moose Role

VERSION
       version 2.2009

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.

   no Moose::Role
       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@iinteractive.com>

       ·   Dave Rolsky <autarch@urth.org>

       ·   Jesse Luehrs <doy@tozt.net>

       ·   Shawn M Moore <code@sartak.org>

       ·   יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>

       ·   Karen Etheridge <ether@cpan.org>

       ·   Florian Ragwitz <rafl@debian.org>

       ·   Hans Dieter Pearcey <hdp@weftsoar.net>

       ·   Chris Prather <chris@prather.org>

       ·   Matt S Trout <mst@shadowcat.co.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.26.1			  2017-12-21		      Moose::Role(3pm)
[top]

List of man pages available for Kali

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net