X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose.pm;h=e80b5232388d2c3d5922cb148449181ee4ae94fa;hb=d67398abd3303d2fb8ed67d78313a202dec7283b;hp=b6d32aee3ecee5e75b680187228490dd691802f5;hpb=c776160203d49277d4501b76ec02ef10d306193b;p=gitmo%2FMoose.git diff --git a/lib/Moose.pm b/lib/Moose.pm index b6d32ae..e80b523 100644 --- a/lib/Moose.pm +++ b/lib/Moose.pm @@ -4,16 +4,17 @@ use warnings; use 5.008; -our $VERSION = '1.00'; +our $VERSION = '1.14'; $VERSION = eval $VERSION; our $AUTHORITY = 'cpan:STEVAN'; use Scalar::Util 'blessed'; use Carp 'confess'; +use Moose::Deprecated; use Moose::Exporter; -use Class::MOP 0.94; +use Class::MOP 1.08; use Moose::Meta::Class; use Moose::Meta::TypeConstraint; @@ -133,6 +134,11 @@ sub init_meta { # This used to be called as a function. This hack preserves # backwards compatibility. if ( $_[0] ne __PACKAGE__ ) { + Moose::Deprecated::deprecated( + feature => 'Moose::init_meta', + message => 'Calling Moose::init_meta as a function is deprecated', + ); + return __PACKAGE__->init_meta( for_class => $_[0], base_class => $_[1], @@ -170,7 +176,7 @@ sub init_meta { # no metaclass, no 'meta' method # now we check whether our ancestors have metaclass, and if so borrow that - my ( undef, @isa ) = @{ $class->mro::get_linear_isa }; + my ( undef, @isa ) = @{ mro::get_linear_isa($class) }; foreach my $ancestor ( @isa ) { my $ancestor_meta = Class::MOP::get_metaclass_by_name($ancestor) || next; @@ -354,7 +360,10 @@ Much of the Moose documentation has been translated into other languages. =item Japanese -Japanese docs can be found at L. The source POD files can be found in GitHub: L +Japanese docs can be found at +L. The +source POD files can be found in GitHub: +L =back @@ -364,8 +373,10 @@ Moose makes every attempt to provide as much convenience as possible during class construction/definition, but still stay out of your way if you want it to. Here are a few items to note when building classes with Moose. -Unless specified with C, any class which uses Moose will -inherit from L. +When you C, Moose will set the class's parent class to +L, I the class using Moose already has a parent +class. In addition, specifying a parent with C will change the parent +class. Moose will also manage all attributes (including inherited ones) that are defined with C. And (assuming you call C, which is inherited from @@ -403,10 +414,31 @@ actually Ces onto the class's C<@ISA>, whereas C will replace it. This is important to ensure that classes which do not have superclasses still properly inherit from L. +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 This will apply a given set of C<@roles> to the local class. +Like with C, 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 %options> This will install an attribute of a given C<$name> into the current class. If @@ -442,9 +474,9 @@ for information on how to define a new type, and how to retrieve type meta-data) =item I (1|0)> This will attempt to use coercion with the supplied type constraint to change -the value passed into any accessors or constructors. You B have supplied -a type constraint in order for this to work. See L -for an example. +the value passed into any accessors or constructors. You B supply a type +constraint, and that type constraint B define a coercion. See +L for an example. =item I $role_name> @@ -951,6 +983,16 @@ for you. An alias for C, used by internally by Moose. +=head2 The MooseX:: namespace + +Generally if you're writing an extension I Moose itself you'll want +to put your extension in the C namespace. This namespace is +specifically for extensions that make Moose better or different in some +fundamental way. It is traditionally B for a package that just happens +to use Moose. This namespace follows from the examples of the C +and C namespaces that perform the same function for C and C +respectively. + =head1 METACLASS COMPATIBILITY AND MOOSE Metaclass compatibility is a thorny subject. You should start by @@ -958,28 +1000,15 @@ reading the "About Metaclass compatibility" section in the C docs. Moose will attempt to resolve a few cases of metaclass incompatibility -when you set the superclasses for a class, unlike C, which -simply dies if the metaclasses are incompatible. - -In actuality, Moose fixes incompatibility for I 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. +when you set the superclasses for a class, in addition to the cases that +C handles. -Moose has two algorithms for fixing metaclass incompatibility. - -The first algorithm is very simple. If all the metaclass for the -parent is a I 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 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 +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 @@ -991,16 +1020,6 @@ parent's and child's original metaclasses. Ultimately, this is all transparent to you except in the case of an unresolvable conflict. -=head2 The MooseX:: namespace - -Generally if you're writing an extension I Moose itself you'll want -to put your extension in the C namespace. This namespace is -specifically for extensions that make Moose better or different in some -fundamental way. It is traditionally B for a package that just happens -to use Moose. This namespace follows from the examples of the C -and C namespaces that perform the same function for C and C -respectively. - =head1 CAVEATS =over 4 @@ -1062,7 +1081,7 @@ early ideas/feature-requests/encouragement/bug-finding. =item L -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.