X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose%2FPolicy.pm;h=4c4e1cbe1482a25251428305e030e93bb3884948;hb=1c037baf68ddfaea08190bf651dc249e79a35092;hp=b609acc7c54278f18e5c42100569d626b820d552;hpb=461dc6d309a34d7c7ba4069f8dc79bbc0321cba7;p=gitmo%2FMoose-Policy.git diff --git a/lib/Moose/Policy.pm b/lib/Moose/Policy.pm index b609acc..4c4e1cb 100644 --- a/lib/Moose/Policy.pm +++ b/lib/Moose/Policy.pm @@ -21,7 +21,7 @@ sub import { my $package = caller(); $package->can('meta') and - croak("'$package' already has a meta() method"); + croak("'$package' already has a meta() method, this is very problematic"); my $metaclass = 'Moose::Meta::Class'; $metaclass = $policy->metaclass($package) @@ -61,73 +61,106 @@ Moose::Policy - moose-mounted police package Foo; - use Moose::Policy 'My::MooseBestPractice'; + use Moose::Policy 'Moose::Policy::FollowPBP'; use Moose; 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 + =head1 DESCRIPTION -This class allows you to specify your project-wide or company-wide Moose -meta policy in one location. +This module allows you to specify your project-wide or even company-wide +Moose meta-policy. -=head1 CAVEAT +Most all of Moose's 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. -=over 4 +This is the first 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. + +=head2 What is a meta-policy? + +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 +Moose class. + +For instance, L enforces that all +specified Moose classes can only use single inheritence. It does this +by trapping the call to C on the metaclass and only allowing +you to assign a single superclass. + +The L policy changes the default behavior of +accessors to fit the recomendations found in Perl Best Practices. + +=head1 CAVEATS -=item YOU MUST +=head2 Always load Moose::Policy first. + +You B put the following line of code: use Moose::Policy 'My::Policy'; -=item BEFORE +before this line: use Moose; -=back +This is because Moose::Policy must be given the opportunity to set the +custom metaclass before Moose has set it's default metaclass. In fact, if +you try to set a Moose::Policy and there is a C method available, +not only will kittens die, but your program will too. + +=head2 Policys are class scoped + +You must repeat the policy for each class you want to us it. It is B +inherited. This may change in the future, probably it will be a Moose::Policy +itself to allow Moose policys to be inherited. -=head2 The Policy +=head1 THE POLICY -The argument to C is a package name. This package is -require()'d and queried for the following constants: +A Policy is set by passing C a package name. This +package is then queried for what metaclasses it should use. The possible +metaclass values are: =over -=item metaclass +=item B -Defaults to C<'Moose::Meta::Class'>. +This defaults to C. -=item attribute_metaclass +=item B -=item instance_metaclass +=item B -=item method_metaclass +=item B =back -These values are then used to setup your $package->meta object. +For examples of what a Policy actually looks like see the examples in +C and the test suite. More docs to come on this later (probably +a cookbook or something). -Your policy package could be simply a list of constants. +=head1 FUTURE PLANS - package My::Policy; - use constant attribute_metaclass => 'My::Moose::Meta::Attribute'; +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. -But the methods are told what package is using the policy, so they could -concievably give different answers. - - package My::FancyPolicy; +=over 4 - sub attribute_metaclass { - my $self = shift; - my ($user_package) = @_; - return('Our::Attributes::Stricter') - if $user_package =~ m/^Private::Banking::Money/; - return('Our::Attributes'); - } +=item Make set of policy roles -=head1 SEE ALSO +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 you meta-policy with relative ease. -L, L +=back =head1 BUGS