X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose%2FRole.pm;h=2e6b187e8197239f6adfde11d3ee0ce151f5649e;hb=db53853c6e04f25ce99fda9c35cc9ec5c2b4ebea;hp=3ca47109781543f2a0bf2a2b8dbd2ae66b4a718c;hpb=0558683c97fd7290b1ec5c62afe1993df80cb7ec;p=gitmo%2FMoose.git diff --git a/lib/Moose/Role.pm b/lib/Moose/Role.pm index 3ca4710..2e6b187 100644 --- a/lib/Moose/Role.pm +++ b/lib/Moose/Role.pm @@ -10,7 +10,8 @@ use Sub::Name 'subname'; use Sub::Exporter; -our $VERSION = '0.05'; +our $VERSION = '0.07'; +our $AUTHORITY = 'cpan:STEVAN'; use Moose (); @@ -29,6 +30,7 @@ use Moose::Util::TypeConstraints; subtype $role => as 'Role' => where { $_->does($role) } + => optimize_as { blessed($_[0]) && $_[0]->can('does') && $_[0]->does($role) } unless find_type_constraint($role); my $meta; @@ -58,7 +60,7 @@ use Moose::Util::TypeConstraints; return subname 'Moose::Role::with' => sub (@) { my (@roles) = @_; confess "Must specify at least one role" unless @roles; - Moose::_load_all_classes(@roles); + Class::MOP::load_class($_) for @roles; ($_->can('meta') && $_->meta->isa('Moose::Meta::Role')) || confess "You can only consume roles, $_ is not a Moose role" foreach @roles; @@ -115,6 +117,10 @@ use Moose::Util::TypeConstraints; }; }, super => sub { + { + no strict 'refs'; + $Moose::SUPER_SLOT{$CALLER} = \*{"${CALLER}::super"}; + } my $meta = _find_meta(); return subname 'Moose::Role::super' => sub {}; }, @@ -179,9 +185,7 @@ Moose::Role - The Moose Role =head1 SYNOPSIS package Eq; - use strict; - use warnings; - use Moose::Role; + use Moose::Role; # automatically turns on strict and warnings requires 'equal'; @@ -193,9 +197,7 @@ Moose::Role - The Moose Role # ... then in your classes package Currency; - use strict; - use warnings; - use Moose; + use Moose; # automatically turns on strict and warnings with 'Eq'; @@ -206,60 +208,61 @@ Moose::Role - The Moose Role =head1 DESCRIPTION -Role support in Moose is coming along quite well. It's best documentation -is still the the test suite, but it is fairly safe to assume Perl 6 style -behavior, and then either refer to the test suite, or ask questions on -#moose if something doesn't quite do what you expect. More complete -documentation is planned and will be included with the next official -(non-developer) release. +Role support in Moose is pretty solid at this point. However, the best +documentation is still the the test suite. It is fairly safe to assume Perl 6 +style behavior and then either refer to the test suite, or ask questions on +#moose if something doesn't quite do what you expect. + +We are planning writing some more documentation in the near future, but nothing +is ready yet, sorry. =head1 EXPORTED FUNCTIONS -Currently Moose::Role supports all of the functions that L exports, -but differs slightly in how some items are handled (see L below -for details). +Moose::Role currently supports all of the functions that L exports, but +differs slightly in how some items are handled (see L below for +details). -Moose::Role also offers two role specific keyword exports: +Moose::Role also offers two role-specific keyword exports: =over 4 =item B Roles can require that certain methods are implemented by any class which -C the role. +C the role. =item B Roles can C other roles, in effect saying "I can never be combined with these C<@role_names>". This is a feature which should not be used -lightly. +lightly. =back =head1 CAVEATS -The role support now has only a few caveats. They are as follows: +Role support has only a few caveats: =over 4 =item * -Roles cannot use the C keyword, it will throw an exception for now. +Roles cannot use the C keyword; it will throw an exception for now. The same is true of the C and C keywords (not sure those really make sense for roles). All other Moose keywords will be I -so that they can be applied to the consuming class. +so that they can be applied to the consuming class. =item * -Role composition does it's best to B 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 are applied -in the order the roles are used. This too means that there is no conflict for -before/around/after modifiers as well. +Role composition does its best to B 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 +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. =item * @@ -268,9 +271,9 @@ The C keyword currently only works with actual methods. A method modifier (before/around/after and override) will not count as a fufillment of the requirement, and neither will an autogenerated accessor for an attribute. -It is likely that the attribute accessors will eventually be allowed to fufill -those requirements, either that or we will introduce a C keyword -of some kind instead. This descision has not yet been finalized. +It is likely that attribute accessors will eventually be allowed to fufill those +requirements, or we will introduce a C keyword of some kind +instead. This decision has not yet been finalized. =back @@ -288,7 +291,7 @@ Christian Hansen Echansen@cpan.orgE =head1 COPYRIGHT AND LICENSE -Copyright 2006 by Infinity Interactive, Inc. +Copyright 2006, 2007 by Infinity Interactive, Inc. L