X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FMoose.pm;h=f776e12a127b7bed408a77d6f6cf2d9e2aae2ab9;hb=21ddc881fd1f14d24ac37a1cefb5677d99d5cc48;hp=9883f00f74feb4bf0934f423413ec077fec16d4f;hpb=ce7545130128a630969657faaaacf8eaff6098f5;p=gitmo%2FMoose.git

diff --git a/lib/Moose.pm b/lib/Moose.pm
index 9883f00..f776e12 100644
--- a/lib/Moose.pm
+++ b/lib/Moose.pm
@@ -12,6 +12,11 @@ use Moose::Exporter;
 
 use Class::MOP;
 
+BEGIN {
+    die "Class::MOP version $Moose::VERSION required--this is version $Class::MOP::VERSION"
+        if $Moose::VERSION && $Class::MOP::VERSION ne $Moose::VERSION;
+}
+
 use Moose::Meta::Class;
 use Moose::Meta::TypeConstraint;
 use Moose::Meta::TypeCoercion;
@@ -127,22 +132,6 @@ Moose::Exporter->setup_import_methods(
 );
 
 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.'
-                . ' Doing so will throw an error in Moose 2.0200.'
-        );
-
-        return __PACKAGE__->init_meta(
-            for_class  => $_[0],
-            base_class => $_[1],
-            metaclass  => $_[2],
-        );
-    }
-
     shift;
     my %args = @_;
 
@@ -152,6 +141,9 @@ sub init_meta {
     my $metaclass  = $args{metaclass}  || 'Moose::Meta::Class';
     my $meta_name  = exists $args{meta_name} ? $args{meta_name} : 'meta';
 
+    Moose->throw_error("The Metaclass $metaclass must be loaded. (Perhaps you forgot to 'use $metaclass'?)")
+        unless Class::MOP::is_class_loaded($metaclass);
+
     Moose->throw_error("The Metaclass $metaclass must be a subclass of Moose::Meta::Class.")
         unless $metaclass->isa('Moose::Meta::Class');
 
@@ -241,7 +233,6 @@ $_->make_immutable(
     Moose::Meta::TypeCoercion::Union
 
     Moose::Meta::Method
-    Moose::Meta::Method::Accessor
     Moose::Meta::Method::Constructor
     Moose::Meta::Method::Destructor
     Moose::Meta::Method::Overridden
@@ -262,9 +253,17 @@ $_->make_immutable(
     Moose::Meta::Role::Application::ToInstance
 );
 
-Moose::Meta::Mixin::AttributeCore->meta->make_immutable(
+$_->make_immutable(
     inline_constructor => 0,
     constructor_name   => undef,
+    # these are Class::MOP accessors, so they need inlining
+    inline_accessors => 1
+    ) for grep { $_->is_mutable }
+    map { $_->meta }
+    qw(
+    Moose::Meta::Method::Accessor
+    Moose::Meta::Method::Delegation
+    Moose::Meta::Mixin::AttributeCore
 );
 
 1;
@@ -424,9 +423,10 @@ hash reference as well.
 
 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<Class::MOP::Attribute>, in addition to the list below which are provided by
-Moose (L<Moose::Meta::Attribute> to be more specific):
+every C<$name> in the list. The C<%options> will be passed to the constructor
+for L<Moose::Meta::Attribute> (which inherits from L<Class::MOP::Attribute>),
+so the full documentation for the valid options can be found there. These are
+the most commonly used options:
 
 =over 4
 
@@ -733,54 +733,21 @@ another role.
 
 Aside from where the attributes come from (one from superclass, the other
 from a role), this feature works exactly the same. This feature is restricted
-somewhat, so as to try and force at least I<some> sanity into it. You are only
-allowed to change the following attributes:
+somewhat, so as to try and force at least I<some> sanity into it. Most options work the same, but there are some exceptions:
 
 =over 4
 
-=item I<default>
-
-Change the default value of an attribute.
-
-=item I<coerce>
-
-Change whether the attribute attempts to coerce a value passed to it.
+=item I<reader>
 
-=item I<required>
+=item I<writer>
 
-Change if the attribute is required to have a value.
+=item I<accessor>
 
-=item I<documentation>
+=item I<clearer>
 
-Change the documentation string associated with the attribute.
+=item I<predicate>
 
-=item I<lazy>
-
-Change if the attribute lazily initializes the slot.
-
-=item I<isa>
-
-You I<are> 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 decision.
-
-=item I<handles>
-
-You are allowed to B<add> a new C<handles> definition, but you are B<not>
-allowed to I<change> one.
-
-=item I<builder>
-
-You are allowed to B<add> a new C<builder> definition, but you are B<not>
-allowed to I<change> one.
-
-=item I<metaclass>
-
-You are allowed to B<add> a new C<metaclass> definition, but you are
-B<not> allowed to I<change> one.
+These options can be added, but cannot override a superclass definition.
 
 =item I<traits>
 
@@ -801,12 +768,6 @@ modifier features that L<Class::MOP> provides. More information on these may be
 found in L<Moose::Manual::MethodModifiers> and the
 L<Class::MOP::Class documentation|Class::MOP::Class/"Method Modifiers">.
 
-=item B<super>
-
-The keyword C<super> is a no-op when called outside of an C<override> method. In
-the context of an C<override> method, it will call the next most appropriate
-superclass method with the same arguments as the original method.
-
 =item B<override ($name, &sub)>
 
 An C<override> method is a way of explicitly saying "I am overriding this
@@ -814,12 +775,11 @@ method from my superclass". You can call C<super> within this method, and
 it will work as expected. The same thing I<can> be accomplished with a normal
 method call and the C<SUPER::> pseudo-package; it is really your choice.
 
-=item B<inner>
+=item B<super>
 
-The keyword C<inner>, much like C<super>, is a no-op outside of the context of
-an C<augment> method. You can think of C<inner> as being the inverse of
-C<super>; the details of how C<inner> and C<augment> work is best described in
-the L<Moose::Cookbook::Basics::Recipe6>.
+The keyword C<super> is a no-op when called outside of an C<override> method. In
+the context of an C<override> method, it will call the next most appropriate
+superclass method with the same arguments as the original method.
 
 =item B<augment ($name, &sub)>
 
@@ -827,26 +787,30 @@ An C<augment> method, is a way of explicitly saying "I am augmenting this
 method from my superclass". Once again, the details of how C<inner> and
 C<augment> work is best described in the L<Moose::Cookbook::Basics::Recipe6>.
 
-=item B<confess>
+=item B<inner>
 
-This is the C<Carp::confess> function, and exported here because I use it
-all the time.
+The keyword C<inner>, much like C<super>, is a no-op outside of the context of
+an C<augment> method. You can think of C<inner> as being the inverse of
+C<super>; the details of how C<inner> and C<augment> work is best described in
+the L<Moose::Cookbook::Basics::Recipe6>.
 
 =item B<blessed>
 
-This is the C<Scalar::Util::blessed> function. It is exported here because I
-use it all the time. It is highly recommended that this is used instead of
-C<ref> anywhere you need to test for an object's class name.
+This is the C<Scalar::Util::blessed> function. It is highly recommended that
+this is used instead of C<ref> anywhere you need to test for an object's class
+name.
 
-=back
+=item B<confess>
 
-=head1 METACLASS
+This is the C<Carp::confess> function, and exported here for historical
+reasons.
 
-When you use Moose, you can specify which metaclass to use:
+=back
 
-    use Moose -metaclass => 'My::Meta::Class';
+=head1 METACLASS
 
-You can also specify traits which will be applied to your metaclass:
+When you use Moose, you can specify traits which will be applied to your
+metaclass:
 
     use Moose -traits => 'My::Trait';
 
@@ -903,38 +867,9 @@ to work. Here is an example:
 To learn more about extending Moose, we recommend checking out the
 "Extending" recipes in the L<Moose::Cookbook>, starting with
 L<Moose::Cookbook::Extending::Recipe1>, which provides an overview of
-all the different ways you might extend Moose.
-
-=head2 B<< Moose->init_meta(for_class => $class, base_class => $baseclass, metaclass => $metaclass) >>
-
-The C<init_meta> method sets up the metaclass object for the class
-specified by C<for_class>. This method injects a a C<meta> accessor
-into the class so you can get at this object. It also sets the class's
-superclass to C<base_class>, with L<Moose::Object> as the default.
-
-C<init_meta> returns the metaclass object for C<$class>.
-
-You can specify an alternate metaclass with the C<metaclass> option.
-
-For more detail on this topic, see L<Moose::Cookbook::Extending::Recipe2>.
-
-This method used to be documented as a function which accepted
-positional parameters. This calling style will still work for
-backwards compatibility, but is deprecated.
-
-=head2 B<import>
-
-Moose's C<import> method supports the L<Sub::Exporter> form of C<{into =E<gt> $pkg}>
-and C<{into_level =E<gt> 1}>.
-
-B<NOTE>: Doing this is more or less deprecated. Use L<Moose::Exporter>
-instead, which lets you stack multiple C<Moose.pm>-alike modules
-sanely. It handles getting the exported functions into the right place
-for you.
-
-=head2 B<throw_error>
-
-An alias for C<confess>, used internally by Moose.
+all the different ways you might extend Moose. L<Moose::Exporter> and
+L<Moose::Util::MetaRole> are the modules which provide the majority of the
+extension functionality, so reading their documentation should also be helpful.
 
 =head2 The MooseX:: namespace
 
@@ -1048,8 +983,6 @@ Part 2 - L<http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
 
 See L<http://search.cpan.org/search?query=MooseX::> for extensions.
 
-=item Moose stats on ohloh.net - L<http://www.ohloh.net/projects/moose>
-
 =back
 
 =head2 Books