X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose.pm;h=8cccad5dcb5f58f9fff5f621960e1de2e7b30c0f;hb=6b2f825e73f66af279fa9e0802bc06a0094e5e89;hp=9e4eae15f7cd4db1902bbd51ccaa4a618084f281;hpb=6d0815b59db07f71cdbfd978ed6f574e57e2b3ea;p=gitmo%2FMoose.git diff --git a/lib/Moose.pm b/lib/Moose.pm index 9e4eae1..8cccad5 100644 --- a/lib/Moose.pm +++ b/lib/Moose.pm @@ -4,16 +4,17 @@ use warnings; use 5.008; -our $VERSION = '0.93'; +our $VERSION = '1.11'; $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.05; 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], @@ -159,13 +165,18 @@ sub init_meta { 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 # 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; @@ -254,6 +265,7 @@ $_->make_immutable( 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 @@ -267,6 +279,11 @@ $_->make_immutable( Moose::Meta::Role::Application::ToInstance ); +Moose::Meta::Mixin::AttributeCore->meta->make_immutable( + inline_constructor => 0, + constructor_name => undef, +); + 1; __END__ @@ -341,7 +358,12 @@ Much of the Moose documentation has been translated into other languages. =over 4 -=item L +=item Japanese + +Japanese docs can be found at +L. The +source POD files can be found in GitHub: +L =back @@ -390,10 +412,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 @@ -458,15 +501,20 @@ If an attribute is marked as lazy it B have a default supplied. =item I (1|0)> -This tells the accessor whether to automatically dereference the value returned. -This is only legal if your C option is either C or C. +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 or +L may be a better +choice. The I option is only legal if your I option is +either C or C. =item I $code> The I 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. If the attribute already had a -value, this will be passed as the third value to the trigger. +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 have a trigger on a read-only attribute. @@ -474,7 +522,7 @@ B Triggers will only fire when you B to the attribute, either in the constructor, or using the writer. Default and built values will B cause the trigger to be fired. -=item I ARRAY | HASH | REGEXP | ROLE | DUCKTYPE | CODE> +=item I ARRAY | HASH | REGEXP | ROLE | ROLETYPE | DUCKTYPE | CODE> The I option provides Moose classes with automated delegation features. This is a pretty complex and powerful option. It accepts many different option @@ -570,13 +618,14 @@ B An I option is required when using the regexp option format. This is so that we can determine (at compile time) the method list from the class. Without an I this is just not possible. -=item C +=item C or C -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 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 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 include any method modifiers or generated attribute methods (which +is consistent with role composition). =item C @@ -786,11 +835,11 @@ B overridden, or removed. =back -=item B sub { ... }> +=item B sub { ... }> -=item B sub { ... }> +=item B sub { ... }> -=item B sub { ... }> +=item B sub { ... }> These three items are syntactic sugar for the before, after, and around method modifier features that L provides. More information on these may be @@ -932,6 +981,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 @@ -939,28 +998,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. - -Moose has two algorithms for fixing metaclass incompatibility. +when you set the superclasses for a class, in addition to the cases that +C handles. -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 @@ -972,16 +1018,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 @@ -1012,9 +1048,9 @@ The mailing list is L. You must be subscribed to send a message. To subscribe, send an empty message to L -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 +This channel is quite active, and questions at all levels (on Moose-related +topics ;) are welcome. =head1 ACKNOWLEDGEMENTS @@ -1043,7 +1079,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. @@ -1092,6 +1128,9 @@ exception. Please report any bugs to C, or through the web interface at L. +You can also discuss feature requests or possible bugs on the Moose mailing +list (moose@perl.org) or on IRC at L. + =head1 FEATURE REQUESTS We are very strict about what features we add to the Moose core, especially @@ -1121,20 +1160,20 @@ but the community as well. Stevan (stevan) Little Estevan@iinteractive.comE +Jesse (doy) Luehrs Edoy at tozt dot netE + Yuval (nothingmuch) Kogman Shawn (sartak) Moore Esartak@bestpractical.comE -Dave (autarch) Rolsky Eautarch@urth.orgE - -Jesse (doy) Luehrs Edoy at tozt dot netE - Hans Dieter (confound) Pearcey Ehdp@pobox.comE Chris (perigrin) Prather Florian Ragwitz Erafl@debian.orgE +Dave (autarch) Rolsky Eautarch@urth.orgE + =head2 OTHER CONTRIBUTORS Aankhen @@ -1179,7 +1218,7 @@ Dylan Hardison (doc fixes) =head1 COPYRIGHT AND LICENSE -Copyright 2006-2009 by Infinity Interactive, Inc. +Copyright 2006-2010 by Infinity Interactive, Inc. L