use 5.008;
-our $VERSION = '0.84';
+our $VERSION = '1.05';
$VERSION = eval $VERSION;
our $AUTHORITY = 'cpan:STEVAN';
use Moose::Exporter;
-use Class::MOP 0.88;
+use Class::MOP 0.94;
use Moose::Meta::Class;
use Moose::Meta::TypeConstraint;
use Moose::Util::TypeConstraints;
use Moose::Util ();
+use Moose::Meta::Attribute::Native;
+
sub throw_error {
# FIXME This
shift;
}
sub extends {
- my $class = shift;
+ my $meta = shift;
Moose->throw_error("Must derive at least one class") unless @_;
# this checks the metaclass to make sure
# it is correct, sometimes it can get out
# of sync when the classes are being built
- Moose::Meta::Class->initialize($class)->superclasses(@_);
+ $meta->superclasses(@_);
}
sub with {
- my $class = shift;
- Moose::Util::apply_all_roles(Class::MOP::Class->initialize($class), @_);
+ Moose::Util::apply_all_roles(shift, @_);
}
sub has {
- my $class = shift;
- my $name = shift;
+ my $meta = shift;
+ my $name = shift;
Moose->throw_error('Usage: has \'name\' => ( key => value, ... )')
if @_ % 2 == 1;
my %options = ( definition_context => Moose::Util::_caller_info(), @_ );
my $attrs = ( ref($name) eq 'ARRAY' ) ? $name : [ ($name) ];
- Class::MOP::Class->initialize($class)->add_attribute( $_, %options ) for @$attrs;
+ $meta->add_attribute( $_, %options ) for @$attrs;
}
sub before {
- my $class = shift;
- Moose::Util::add_method_modifier($class, 'before', \@_);
+ Moose::Util::add_method_modifier(shift, 'before', \@_);
}
sub after {
- my $class = shift;
- Moose::Util::add_method_modifier($class, 'after', \@_);
+ Moose::Util::add_method_modifier(shift, 'after', \@_);
}
sub around {
- my $class = shift;
- Moose::Util::add_method_modifier($class, 'around', \@_);
+ Moose::Util::add_method_modifier(shift, 'around', \@_);
}
our $SUPER_PACKAGE;
}
sub override {
- my $class = shift;
+ my $meta = shift;
my ( $name, $method ) = @_;
- Class::MOP::Class->initialize($class)->add_override_method_modifier( $name => $method );
+ $meta->add_override_method_modifier( $name => $method );
}
sub inner {
}
sub augment {
- my $class = shift;
+ my $meta = shift;
my ( $name, $method ) = @_;
- Class::MOP::Class->initialize($class)->add_augment_method_modifier( $name => $method );
+ $meta->add_augment_method_modifier( $name => $method );
}
Moose::Exporter->setup_import_methods(
- with_caller => [
- qw( extends with has before after around override augment)
+ with_meta => [
+ qw( extends with has before after around override augment )
],
as_is => [
qw( super inner ),
if ( $meta = Class::MOP::get_metaclass_by_name($class) ) {
unless ( $meta->isa("Moose::Meta::Class") ) {
- Moose->throw_error("$class already has a metaclass, but it does not inherit $metaclass ($meta)");
+ my $error_message = "$class already has a metaclass, but it does not inherit $metaclass ($meta).";
+ if ( $meta->isa('Moose::Meta::Role') ) {
+ Moose->throw_error($error_message . ' You cannot make the same thing a role and a class. Remove either Moose or Moose::Role.');
+ } else {
+ Moose->throw_error($error_message);
+ }
}
} else {
# no metaclass, no 'meta' method
my $ancestor_meta = Class::MOP::get_metaclass_by_name($ancestor) || next;
my $ancestor_meta_class = ($ancestor_meta->is_immutable
- ? $ancestor_meta->get_mutable_metaclass_name
+ ? $ancestor_meta->_get_mutable_metaclass_name
: ref($ancestor_meta));
# if we have an ancestor metaclass that inherits $metaclass, we use
Moose::Meta::Method::Augmented
Moose::Meta::Role
+ Moose::Meta::Role::Attribute
Moose::Meta::Role::Method
Moose::Meta::Role::Method::Required
Moose::Meta::Role::Method::Conflicting
Moose::Meta::Role::Application::ToInstance
);
+Moose::Meta::Mixin::AttributeCore->meta->make_immutable(
+ inline_constructor => 0,
+ constructor_name => undef,
+);
+
1;
__END__
or to examine L<Task::Moose> which aims to keep an up-to-date, easily
installable list of Moose extensions.
+=head1 TRANSLATIONS
+
+Much of the Moose documentation has been translated into other languages.
+
+=over 4
+
+=item Japanese
+
+Japanese docs can be found at L<http://perldoc.perlassociation.org/pod/Moose-Doc-JA/index.html>. The source POD files can be found in GitHub: L<http://github.com/jpa/Moose-Doc-JA>
+
+=back
+
=head1 BUILDING CLASSES WITH MOOSE
Moose makes every attempt to provide as much convenience as possible during
replace it. This is important to ensure that classes which do not have
superclasses still properly inherit from L<Moose::Object>.
+Each superclass can be followed by a hash reference with options. Currently,
+only L<-version|Class::MOP/Class Loading Options> is recognized:
+
+ extends 'My::Parent' => { -version => 0.01 },
+ 'My::OtherParent' => { -version => 0.03 };
+
+An exception will be thrown if the version requirements are not
+satisfied.
+
=item B<with (@roles)>
This will apply a given set of C<@roles> to the local class.
+Like with C<extends>, each specified role can be followed by a hash
+reference with a L<-version|Class::MOP/Class Loading Options> option:
+
+ with 'My::Role' => { -version => 0.32 },
+ 'My::Otherrole' => { -version => 0.23 };
+
+The specified version requirements must be satisfied, otherwise an
+exception will be thrown.
+
+If your role takes options or arguments, they can be passed along in the
+hash reference as well.
+
=item B<has $name|@$names =E<gt> %options>
This will install an attribute of a given C<$name> into the current class. If
=item I<auto_deref =E<gt> (1|0)>
-This tells the accessor whether to automatically dereference the value returned.
-This is only legal if your C<isa> option is either C<ArrayRef> or C<HashRef>.
+This tells the accessor to automatically dereference the value of this
+attribute when called in list context. The accessor will still return a
+reference when called in scalar context. If this behavior isn't desirable,
+L<Moose::Meta::Attribute::Native::Trait::Array/elements> or
+L<Moose::Meta::Attribute::Native::Trait::Hash/elements> may be a better
+choice. The I<auto_deref> option is only legal if your I<isa> option is
+either C<ArrayRef> or C<HashRef>.
=item I<trigger =E<gt> $code>
The I<trigger> option is a CODE reference which will be called after
-the value of the attribute is set. The CODE ref will be passed the
-instance itself and the updated value. You B<can> have a trigger on
-a read-only attribute.
+the value of the attribute is set. The CODE ref is passed the
+instance itself, the updated value, and the original value if the
+attribute was already set.
+
+You B<can> have a trigger on a read-only attribute.
B<NOTE:> Triggers will only fire when you B<assign> to the attribute,
either in the constructor, or using the writer. Default and built values will
B<not> cause the trigger to be fired.
-=item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | DUCKTYPE | CODE>
+=item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | ROLETYPE | DUCKTYPE | CODE>
The I<handles> option provides Moose classes with automated delegation features.
This is a pretty complex and powerful option. It accepts many different option
which delegate to the C<node> and C<children> methods (respectively) of the Tree
instance stored in the C<parent> slot.
+You may also use an array reference to curry arguments to the original method.
+
+ has 'thing' => (
+ ...
+ handles => { set_foo => [ set => 'foo' ] },
+ );
+
+ # $self->set_foo(...) calls $self->thing->set('foo', ...)
+
+The first element of the array reference is the original method name, and the
+rest is a list of curried arguments.
+
=item C<REGEXP>
The regexp option works very similar to the ARRAY option, except that it builds
is so that we can determine (at compile time) the method list from the class.
Without an I<isa> this is just not possible.
-=item C<ROLE>
+=item C<ROLE> or C<ROLETYPE>
-With the role option, you specify the name of a role whose "interface" then
-becomes the list of methods to handle. The "interface" can be defined as; the
-methods of the role and any required methods of the role. It should be noted
-that this does B<not> include any method modifiers or generated attribute
-methods (which is consistent with role composition).
+With the role option, you specify the name of a role or a
+L<role type|Moose::Meta::TypeConstraint::Role> whose "interface" then becomes
+the list of methods to handle. The "interface" can be defined as; the methods
+of the role and any required methods of the role. It should be noted that this
+does B<not> include any method modifiers or generated attribute methods (which
+is consistent with role composition).
=item C<DUCKTYPE>
becomes the list of methods to handle. The "interface" can be defined as; the
list of methods passed to C<duck_type> to create a duck type object. For more
information on C<duck_type> please check
-L<Moose::Util::TypeConstraint|Moose::Util::TypeConstraint>.
+L<Moose::Util::TypeConstraints>.
=item C<CODE>
but they are still a fairly advanced topic and too much to cover here, see
L<Moose::Cookbook::Meta::Recipe1> for more information.
-The default behavior here is to just load C<$metaclass_name>; however, we also
-have a way to alias to a shorter name. This will first look to see if
-B<Moose::Meta::Attribute::Custom::$metaclass_name> exists. If it does, Moose
-will then check to see if that has the method C<register_implementation>, which
-should return the actual name of the custom attribute metaclass. If there is no
-C<register_implementation> method, it will fall back to using
-B<Moose::Meta::Attribute::Custom::$metaclass_name> as the metaclass name.
+See L<Metaclass and Trait Name Resolution> for details on how a metaclass name
+is resolved to a class name.
=item I<traits =E<gt> [ @role_names ]>
attribute meta-object. This is very similar to the I<metaclass> option, but
allows you to use more than one extension at a time.
-See L<TRAIT NAME RESOLUTION> for details on how a trait name is
-resolved to a class name.
+See L<Metaclass and Trait Name Resolution> for details on how a trait name is
+resolved to a role name.
Also see L<Moose::Cookbook::Meta::Recipe3> for a metaclass trait
example.
The value of this key is the name of the method that will be called to
obtain the value used to initialize the attribute. See the L<builder
option docs in Class::MOP::Attribute|Class::MOP::Attribute/builder>
- and/or L<Moose::Cookbook::Basics::Recipe9> for more information.
+ and/or L<Moose::Cookbook::Basics::Recipe8> for more information.
=item I<default> => SCALAR | CODE
=back
-=item B<before $name|@names =E<gt> sub { ... }>
+=item B<before $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
-=item B<after $name|@names =E<gt> sub { ... }>
+=item B<after $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
-=item B<around $name|@names =E<gt> sub { ... }>
+=item B<around $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
-This three items are syntactic sugar for the before, after, and around method
+These three items are syntactic sugar for the before, after, and around method
modifier features that L<Class::MOP> provides. More information on these may be
-found in the L<Class::MOP::Class documentation|Class::MOP::Class/"Method
-Modifiers"> for now.
+found in L<Moose::Manual::MethodModifiers> and the
+L<Class::MOP::Class documentation|Class::MOP::Class/"Method Modifiers">.
=item B<super>
This is very similar to the attribute traits feature. When you do
this, your class's C<meta> object will have the specified traits
-applied to it. See L<TRAIT NAME RESOLUTION> for more details.
+applied to it. See L<Metaclass and Trait Name Resolution> for more
+details.
-=head2 Trait Name Resolution
+=head2 Metaclass and Trait Name Resolution
By default, when given a trait name, Moose simply tries to load a
class of the same name. If such a class does not exist, it then looks
C<register_implementation> method, it will fall back to using
B<Moose::Meta::$type::Custom::Trait::$trait> as the trait name.
+The lookup method for metaclasses is the same, except that it looks
+for a class matching B<Moose::Meta::$type::Custom::$metaclass_name>.
+
If all this is confusing, take a look at
L<Moose::Cookbook::Meta::Recipe3>, which demonstrates how to create an
attribute trait.
C<Class::MOP> docs.
Moose will attempt to resolve a few cases of metaclass incompatibility
-when you set the superclasses for a class, unlike C<Class::MOP>, which
-simply dies if the metaclasses are incompatible.
-
-In actuality, Moose fixes incompatibility for I<all> of a class's
-metaclasses, not just the class metaclass. That includes the instance
-metaclass, attribute metaclass, as well as its constructor class and
-destructor class. However, for simplicity this discussion will just
-refer to "metaclass", meaning the class metaclass, most of the time.
-
-Moose has two algorithms for fixing metaclass incompatibility.
+when you set the superclasses for a class, in addition to the cases that
+C<Class::MOP> handles.
-The first algorithm is very simple. If all the metaclass for the
-parent is a I<subclass> of the child's metaclass, then we simply
-replace the child's metaclass with the parent's.
-
-The second algorithm is more complicated. It tries to determine if the
-metaclasses only "differ by roles". This means that the parent and
-child's metaclass share a common ancestor in their respective
-hierarchies, and that the subclasses under the common ancestor are
-only different because of role applications. This case is actually
-fairly common when you mix and match various C<MooseX::*> modules,
-many of which apply roles to the metaclass.
+Moose tries to determine if the metaclasses only "differ by roles". This
+means that the parent and child's metaclass share a common ancestor in
+their respective hierarchies, and that the subclasses under the common
+ancestor are only different because of role applications. This case is
+actually fairly common when you mix and match various C<MooseX::*>
+modules, many of which apply roles to the metaclass.
If the parent and child do differ by roles, Moose replaces the
metaclass in the child with a newly created metaclass. This metaclass
a message. To subscribe, send an empty message to
L<moose-subscribe@perl.org>
-You can also visit us at L<#moose on
-irc.perl.org|irc://irc.perl.org/#moose>. This channel is quite active,
-and questions at all levels (on Moose-related topics ;) are welcome.
+You can also visit us at C<#moose> on L<irc://irc.perl.org/#moose>
+This channel is quite active, and questions at all levels (on Moose-related
+topics ;) are welcome.
=head1 ACKNOWLEDGEMENTS
=item L<http://www.iinteractive.com/moose>
-This is the official web home of Moose, it contains links to our public SVN repository
+This is the official web home of Moose, it contains links to our public git repository
as well as links to a number of talks and articles on Moose and Moose related
technologies.
Please report any bugs to C<bug-moose@rt.cpan.org>, or through the web
interface at L<http://rt.cpan.org>.
+You can also discuss feature requests or possible bugs on the Moose mailing
+list (moose@perl.org) or on IRC at L<irc://irc.perl.org/#moose>.
+
=head1 FEATURE REQUESTS
We are very strict about what features we add to the Moose core, especially
Stevan (stevan) Little E<lt>stevan@iinteractive.comE<gt>
+Jesse (doy) Luehrs E<lt>doy at tozt dot netE<gt>
+
Yuval (nothingmuch) Kogman
-Shawn (sartak) Moore
+Shawn (sartak) Moore E<lt>sartak@bestpractical.comE<gt>
+
+Hans Dieter (confound) Pearcey E<lt>hdp@pobox.comE<gt>
+
+Chris (perigrin) Prather
+
+Florian Ragwitz E<lt>rafl@debian.orgE<gt>
Dave (autarch) Rolsky E<lt>autarch@urth.orgE<gt>
Christian (chansen) Hansen
-Hans Dieter (confound) Pearcey
-
Eric (ewilhelm) Wilhelm
Guillermo (groditi) Roditi
Shlomi (rindolf) Fish
-Chris (perigrin) Prather
-
Wallace (wreis) Reis
Jonathan (jrockway) Rockway
=head1 COPYRIGHT AND LICENSE
-Copyright 2006-2009 by Infinity Interactive, Inc.
+Copyright 2006-2010 by Infinity Interactive, Inc.
L<http://www.iinteractive.com>
projects / gitmo/Moose.git / blobdiff