Manual Reference Pages - MOOSE::POLICY (3)
Moose::Policy - Moose-mounted police
use Moose::Policy Moose::Policy::FollowPBP;
has bar => (is => rw, default => Foo::bar);
has baz => (is => ro, default => Foo::baz);
# Foo now has (get, set)_bar methods as well as get_baz
<B>Moose::Policy is deprecatedB>.
MooseX::FollowPBP replaces the Moose::Policy::FollowPBP module. The
other policies included in this distribution do not yet have standalone MooseX
modules, as of November, 2010.
This module has not passed its tests since Moose 1.05, and will probably not
This module allows you to specify your project-wide or even company-wide
Most all of Mooses features can be customized through the use of custom
metaclasses, however fiddling with the metaclasses can be hairy. Moose::Policy
removes most of that hairiness and makes it possible to cleanly contain
a set of meta-level customizations in one easy to use module.
This is still an release of this module and it should not be considered to
be complete by any means. It is very basic implemenation at this point and
will likely get more feature-full over time, as people request features.
So if you have a suggestion/need/idea, please speak up.
A meta-policy is a set of custom Moose metaclasses which can be used to
implement a number of customizations and restrictions on a particular
For instance, Moose::Policy::SingleInheritence enforces that all
specified Moose classes can only use single inheritance. It does this
by trapping the call to superclasses on the metaclass and only allowing
you to assign a single superclass.
The Moose::Policy::FollowPBP policy changes the default behavior of
accessors to fit the recomendations found in Perl Best Practices.
Always load Moose::Policy first.
You <B>mustB> put the following line of code:
use Moose::Policy My::Policy;
before this line:
This is because Moose::Policy must be given the opportunity to set the
custom metaclass before Moose has set its default metaclass. In fact, if
you try to set a Moose::Policy and there is a meta method available,
not only will kittens die, but your program will too.
Policies are class scoped
You must repeat the policy for each class you want to use it. It is <B>notB>
inherited. This may change in the future, probably it will be a Moose::Policy
itself to allow Moose policies to be inherited.
A Policy is set by passing Moose::Policy::import() a package name. This
package is then queried for what metaclasses it should use. The possible
metaclass values are:
For examples of what a Policy actually looks like see the examples in
Moose::Policy:: and the test suite. More docs to come on this later (probably
a cookbook or something).
This defaults to Moose::Meta::Class.
As I said above, this is the first release and it is by no means feature complete.
There are a number of thoughts on the future direction of this module. Here are
some random thoughts on that, in no particular order.
Make set of policy roles
Roles are an excellent way to combine sets of behaviors together into one, and
custom metaclasses are actually better composed by roles then by inheritence.
The ideal situation is that this module will provide a set of roles which can be
used to compose your meta-policy with relative ease.
All complex software has bugs lurking in it, and this module is no
exception. If you find a bug please either email me, or add the bug
Stevan Little <email@example.com>
COPYRIGHT AND LICENSE
Copyright 2006-2007 by Infinity Interactive, Inc.
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
|perl v5.20.3 ||MOOSE::POLICY (3) ||2010-11-21 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.