use Sub::Exporter;
-our $VERSION = '0.06';
+our $VERSION = '0.07';
+our $AUTHORITY = 'cpan:STEVAN';
use Moose ();
subtype $role
=> as 'Role'
=> where { $_->does($role) }
- => optimize_as { blessed($_[0]) && $_[0]->can('does') && $_[0]->does($role) }
+ => optimize_as { blessed($_[0]) && $_[0]->can('does') && $_[0]->does($role) }
unless find_type_constraint($role);
my $meta;
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;
};
},
super => sub {
+ {
+ no strict 'refs';
+ $Moose::SUPER_SLOT{$CALLER} = \*{"${CALLER}::super"};
+ }
my $meta = _find_meta();
return subname 'Moose::Role::super' => sub {};
},
});
sub import {
- $CALLER = caller();
+ $CALLER =
+ ref $_[1] && defined $_[1]->{into} ? $_[1]->{into}
+ : ref $_[1]
+ && defined $_[1]->{into_level} ? caller( $_[1]->{into_level} )
+ : caller();
+
strict->import;
warnings->import;
=head1 SYNOPSIS
package Eq;
- use strict;
- use warnings;
- use Moose::Role;
+ use Moose::Role; # automatically turns on strict and warnings
requires 'equal';
# ... then in your classes
package Currency;
- use strict;
- use warnings;
- use Moose;
+ use Moose; # automatically turns on strict and warnings
with 'Eq';
=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<Moose> exports,
-but differs slightly in how some items are handled (see L<CAVEATS> below
-for details).
+Moose::Role currently supports all of the functions that L<Moose> exports, but
+differs slightly in how some items are handled (see L<CAVEATS> 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<requires (@method_names)>
Roles can require that certain methods are implemented by any class which
-C<does> the role.
+C<does> the role.
=item B<excludes (@role_names)>
Roles can C<exclude> 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<extends> keyword, it will throw an exception for now.
+Roles cannot use the C<extends> keyword; it will throw an exception for now.
The same is true of the C<augment> and C<inner> keywords (not sure those
really make sense for roles). All other Moose keywords will be I<deferred>
-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<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 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<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
+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 *
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<requires_attr> 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<requires_attr> keyword of some kind
+instead. This decision has not yet been finalized.
=back
=head1 COPYRIGHT AND LICENSE
-Copyright 2006 by Infinity Interactive, Inc.
+Copyright 2006, 2007 by Infinity Interactive, Inc.
L<http://www.iinteractive.com>