X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose.pm;h=2c0022410da0441f493cce12c3d82137aa9435e7;hb=82750a8aa67b0f6cd139537bef64162d7a7c4d52;hp=a70af0726b1476b1641e75e3546bd51fc5f3a17b;hpb=41419b9e140e4b1b2c7d2de18649151993206509;p=gitmo%2FMoose.git diff --git a/lib/Moose.pm b/lib/Moose.pm index a70af07..2c00224 100644 --- a/lib/Moose.pm +++ b/lib/Moose.pm @@ -6,7 +6,7 @@ use warnings; use 5.008; -our $VERSION = '0.57'; +our $VERSION = '0.62_01'; $VERSION = eval $VERSION; our $AUTHORITY = 'cpan:STEVAN'; @@ -15,7 +15,7 @@ use Carp 'confess', 'croak', 'cluck'; use Moose::Exporter; -use Class::MOP 0.65; +use Class::MOP 0.71; use Moose::Meta::Class; use Moose::Meta::TypeConstraint; @@ -61,7 +61,7 @@ sub extends { # this checks the metaclass to make sure # it is correct, sometimes it can get out # of sync when the classes are being built - my $meta = Moose::Meta::Class->initialize($class)->_fix_metaclass_incompatibility(@supers); + my $meta = Moose::Meta::Class->initialize($class); $meta->superclasses(@supers); } @@ -124,16 +124,9 @@ sub augment { Class::MOP::Class->initialize($class)->add_augment_method_modifier( $name => $method ); } -sub make_immutable { - my $class = shift; - cluck "The make_immutable keyword has been deprecated, " . - "please go back to __PACKAGE__->meta->make_immutable\n"; - Class::MOP::Class->initialize($class)->make_immutable(@_); -} - Moose::Exporter->setup_import_methods( with_caller => [ - qw( extends with has before after around override augment make_immutable ) + qw( extends with has before after around override augment) ], as_is => [ qw( super inner ), @@ -244,24 +237,18 @@ sub _get_caller { ## make 'em all immutable -$_->meta->make_immutable( +$_->make_immutable( inline_constructor => 1, constructor_name => "_new", - inline_accessors => 1, # these are Class::MOP accessors, so they need inlining - ) - for (qw( + # these are Class::MOP accessors, so they need inlining + inline_accessors => 1 + ) for grep { $_->is_mutable } + map { $_->meta } + qw( Moose::Meta::Attribute Moose::Meta::Class Moose::Meta::Instance - Moose::Meta::TypeConstraint - Moose::Meta::TypeConstraint::Union - Moose::Meta::TypeConstraint::Parameterized - Moose::Meta::TypeConstraint::Parameterizable - Moose::Meta::TypeConstraint::Enum - Moose::Meta::TypeConstraint::Class - Moose::Meta::TypeConstraint::Role - Moose::Meta::TypeConstraint::Registry Moose::Meta::TypeCoercion Moose::Meta::TypeCoercion::Union @@ -283,7 +270,7 @@ $_->meta->make_immutable( Moose::Meta::Role::Application::ToClass Moose::Meta::Role::Application::ToRole Moose::Meta::Role::Application::ToInstance -)); +); 1; @@ -402,12 +389,13 @@ superclasses still properly inherit from L. This will apply a given set of C<@roles> to the local class. -=item B %options> +=item B %options> -This will install an attribute of a given C<$name> into the current class. -The C<%options> are the same as those provided by -L, in addition to the list below which are provided -by Moose (L to be more specific): +This will install an attribute of a given C<$name> into the current class. If +the first parameter is an array reference, it will create an attribute for +every C<$name> in the list. The C<%options> are the same as those provided by +L, in addition to the list below which are provided by +Moose (L to be more specific): =over 4 @@ -417,10 +405,12 @@ The I option accepts either I (for read/write) or I (for read only). These will create either a read/write accessor or a read-only accessor respectively, using the same name as the C<$name> of the attribute. -If you need more control over how your accessors are named, you can use the -I, I and I options inherited from -L, however if you use those, you won't need the I -option. +If you need more control over how your accessors are named, you can +use the L, +L and +L options inherited from +L, however if you use those, you won't need the +I option. =item I $type_name> @@ -471,7 +461,11 @@ The I option is a CODE reference which will be called after the value o the attribute is set. The CODE ref will be passed the instance itself, the updated value and the attribute meta-object (this is for more advanced fiddling and can typically be ignored). You B have a trigger on a read-only -attribute. +attribute. + +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 | CODE> @@ -606,11 +600,58 @@ resolved to a class name. Also see L for a metaclass trait example. +=item I => Str + +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 +for more information. + +=item I => SCALAR | CODE + +The value of this key is the default value which will initialize the attribute. + +NOTE: If the value is a simple scalar (string or number), then it can +be just passed as is. However, if you wish to initialize it with a +HASH or ARRAY ref, then you need to wrap that inside a CODE reference. +See the L for more +information. + +=item I => Str + +This may be a method name (referring to a method on the class with +this attribute) or a CODE ref. The initializer is used to set the +attribute value on an instance when the attribute is set during +instance initialization (but not when the value is being assigned +to). See the L for more +information. + +=item I => Str + +Allows you to clear the value, see the L for more +information. + +=item I => Str + +Basic test to see if a value has been set in the attribute, see the +L for more +information. + +=item I => (0|1) + +Automatically define lazy => 1 as well as builder => "_build_$attr", clearer => +"clear_$attr', predicate => 'has_$attr' unless they are already defined. + + =back =item B %options> -This is variation on the normal attibute creator C which allows you to +This is variation on the normal attribute creator C which allows you to clone and extend an attribute from a superclass or from a role. Here is an example of the superclass usage: @@ -689,7 +730,7 @@ You I allowed to change the type without restriction. It is recommended that you use this freedom with caution. We used to only allow for extension only if the type was a subtype of the parent's type, but we felt that was too restrictive and is better left as a -policy descision. +policy decision. =item I @@ -847,10 +888,60 @@ instead, which lets you stack multiple C-alike modules sanely. It handles getting the exported functions into the right place for you. -=head2 throw_error +=head2 B An alias for C, used by internally by Moose. +=head1 METACLASS COMPATIBILITY AND MOOSE + +Metaclass compatibility is a thorny subject. You should start by +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. + +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. + +If the parent and child do differ by roles, Moose replaces the +metaclass in the child with a newly created metaclass. This metaclass +is a subclass of the parent's metaclass, does all of the roles that +the child's metaclass did before being replaced. Effectively, this +means the new metaclass does all of the roles done by both the +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 @@ -966,9 +1057,26 @@ either email the mailing list or join us on irc at #moose to discuss. =head1 AUTHOR -Stevan Little Estevan@iinteractive.comE +Moose is an open project, there are at this point dozens of people who have +contributed, and can contribute. If you have added anything to the Moose +project you have a commit bit on this file and can add your name to the list. + +=head2 CABAL -B +However there are only a few people with the rights to release a new version +of Moose. The Moose Cabal are the people to go to with questions regarding +the wider purview of Moose, and help out maintaining not just the code +but the community as well. + +Stevan (stevan) Little Estevan@iinteractive.comE + +Yuval (nothingmuch) Kogman + +Shawn (sartak) Moore + +Dave (autarch) Rolsky Eautarch@urth.orgE + +=head2 OTHER CONTRIBUTORS Aankhen @@ -998,22 +1106,16 @@ Scott (konobi) McWhirter Shlomi (rindolf) Fish -Yuval (nothingmuch) Kogman - Chris (perigrin) Prather Wallace (wreis) Reis Jonathan (jrockway) Rockway -Dave (autarch) Rolsky - Piotr (dexter) Roszatycki Sam (mugwump) Vilain -Shawn (sartak) Moore - ... and many other #moose folks =head1 COPYRIGHT AND LICENSE