Provided by: libmoose-perl_2.2009-1_amd64 
NAME
Moose::Manual::MooseX - Recommended Moose extensions
VERSION
version 2.2009
MooseX?
It's easy to extend and change Moose, and this is part of what makes Moose so powerful.
You can use the MOP API to do things your own way, add new features, and generally
customize your Moose.
Writing your own extensions does require a good understanding of the meta-model. You can
start learning about this with the Moose::Manual::MOP docs. There are also several
extension recipes in the Moose::Cookbook.
Explaining how to write extensions is beyond the scope of this manual. Fortunately, lots
of people have already written extensions and put them on CPAN for you.
This document covers a few of the ones we like best.
MooseX::AttributeHelpers
The functionality of this MooseX module has been moved into Moose core. See
Moose::Meta::Attribute::Native.
Moose::Autobox
MooseX::AttributeHelpers, but turned inside out, Moose::Autobox provides methods on both
arrays/hashes/etc. but also references to them, using Moose roles, allowing you do to
things like:
use Moose::Autobox;
$somebody_elses_object->orders->push($order);
Lexically scoped and not to everybody's taste, but very handy for sugaring up other
people's APIs and your own code.
MooseX::StrictConstructor
By default, Moose lets you pass any old junk into a class's constructor. If you load
MooseX::StrictConstructor, your class will throw an error if it sees something it doesn't
recognize;
package User;
use Moose;
use MooseX::StrictConstructor;
has 'name';
has 'email';
User->new( name => 'Bob', emali => 'bob@example.com' );
With MooseX::StrictConstructor, that typo ("emali") will cause a runtime error. With plain
old Moose, the "emali" attribute would be silently ignored.
MooseX::Params::Validate
We have high hopes for the future of MooseX::Method::Signatures and Moops. However, these
modules, while used regularly in production by some of the more insane members of the
community, are still marked alpha just in case backwards incompatible changes need to be
made.
If you don't want to risk that, for now we recommend the decidedly more clunky (but also
faster and simpler) MooseX::Params::Validate. This module lets you apply Moose types and
coercions to any method arguments.
package User;
use Moose;
use MooseX::Params::Validate;
sub login {
my $self = shift;
my ($password)
= validated_list( \@_, password => { isa => 'Str', required => 1 } );
...
}
MooseX::Getopt
This is a role which adds a "new_with_options" method to your class. This is a constructor
that takes the command line options and uses them to populate attributes.
This makes writing a command-line application as a module trivially simple:
package App::Foo;
use Moose;
with 'MooseX::Getopt';
has 'input' => (
is => 'ro',
isa => 'Str',
required => 1
);
has 'output' => (
is => 'ro',
isa => 'Str',
required => 1
);
sub run { ... }
Then in the script that gets run we have:
use App::Foo;
App::Foo->new_with_options->run;
From the command line, someone can execute the script:
foo@example> foo --input /path/to/input --output /path/to/output
MooseX::Singleton
To be honest, using a singleton is just a way to have a magic global variable in languages
that don't actually have global variables.
In perl, you can just as easily use a global. However, if your colleagues are Java-
infected, they might prefer a singleton. Also, if you have an existing class that isn't a
singleton but should be, using MooseX::Singleton is the easiest way to convert it.
package Config;
use MooseX::Singleton; # instead of Moose
has 'cache_dir' => ( ... );
It's that simple.
EXTENSIONS TO CONSIDER
There are literally dozens of other extensions on CPAN. This is a list of extensions that
you might find useful, but we're not quite ready to endorse just yet.
MooseX::Declare
MooseX::Declare is based on Devel::Declare, a giant bag of crack originally implemented by
mst with the goal of upsetting the perl core developers so much by its very existence that
they implemented proper keyword handling in the core.
As of perl5 version 14, this goal has been achieved, and modules such as
Devel::CallParser, Function::Parameters, and Keyword::Simple provide mechanisms to mangle
perl syntax that don't require hallucinogenic drugs to interpret the error messages they
produce.
If you want to use declarative syntax in new code, please for the love of kittens get
yourself a recent perl and look at Moops instead.
MooseX::Types
This extension helps you build a type library for your application. It also lets you
predeclare type names and use them as barewords.
use MooseX::Types -declare => ['PositiveInt'];
use MooseX::Types::Moose 'Int';
subtype PositiveInt,
as Int,
where { $_ > 0 },
message { "Int is not larger than 0" };
One nice feature is that those bareword names are actually namespaced in Moose's type
registry, so multiple applications can use the same bareword names, even if the type
definitions differ.
MooseX::Types::Structured
This extension builds on top of MooseX::Types to let you declare complex data structure
types.
use MooseX::Types -declare => [ qw( Name Color ) ];
use MooseX::Types::Moose qw(Str Int);
use MooseX::Types::Structured qw(Dict Tuple Optional);
subtype Name
=> as Dict[ first => Str, middle => Optional[Str], last => Str ];
subtype Color
=> as Tuple[ Int, Int, Int, Optional[Int] ];
Of course, you could always use objects to represent these sorts of things too.
MooseX::ClassAttribute
This extension provides class attributes for Moose classes. The declared class attributes
are introspectable just like regular Moose attributes.
package User;
use Moose;
use MooseX::ClassAttribute;
has 'name' => ( ... );
class_has 'Cache' => ( ... );
Note however that this class attribute does not inherit like a Class::Data::Inheritable or
similar attribute - calling
$subclass->Cache($cache);
will set it for the superclass as well. Additionally, class data is usually The Wrong
Thing To Do in a strongly OO program since it makes testing a lot harder - consider
carefully whether you'd be better off with an object that's passed around instead.
MooseX::Daemonize
This is a role that provides a number of methods useful for creating a daemon, including
methods for starting and stopping, managing a PID file, and signal handling.
MooseX::Role::Parameterized
If you find yourself wanting a role that customizes itself for each consumer, this is the
tool for you. With this module, you can create a role that accepts parameters and
generates attributes, methods, etc. on a customized basis for each consumer.
MooseX::POE
This is a small wrapper that ties together a Moose class with "POE::Session", and gives
you an "event" sugar function to declare event handlers.
MooseX::FollowPBP
Automatically names all accessors Perl Best Practices-style, "get_size" and "set_size".
MooseX::SemiAffordanceAccessor
Automatically names all accessors with an explicit set and implicit get, "size" and
"set_size".
MooseX::NonMoose
MooseX::NonMoose allows for easily subclassing non-Moose classes with Moose, taking care
of the annoying details connected with doing this, such as setting up proper inheritance
from Moose::Object and installing (and inlining, at make_immutable time) a constructor
that makes sure things like BUILD methods are called.
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.