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;
# 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],
# 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;
=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>
+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
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<extends>, any class which uses Moose will
-inherit from L<Moose::Object>.
+When you C<use Moose>, Moose will set the class's parent class to
+L<Moose::Object>, I<unless> the class using Moose already has a parent
+class. In addition, specifying a parent with C<extends> will change the parent
+class.
Moose will also manage all attributes (including inherited ones) that are
defined with C<has>. And (assuming you call C<new>, which is inherited from
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<coerce =E<gt> (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<must> have supplied
-a type constraint in order for this to work. See L<Moose::Cookbook::Basics::Recipe5>
-for an example.
+the value passed into any accessors or constructors. You B<must> supply a type
+constraint, and that type constraint B<must> define a coercion. See
+L<Moose::Cookbook::Basics::Recipe5> for an example.
=item I<does =E<gt> $role_name>
An alias for C<confess>, used by internally by Moose.
+=head2 The MooseX:: namespace
+
+Generally if you're writing an extension I<for> Moose itself you'll want
+to put your extension in the C<MooseX::> namespace. This namespace is
+specifically for extensions that make Moose better or different in some
+fundamental way. It is traditionally B<not> for a package that just happens
+to use Moose. This namespace follows from the examples of the C<LWPx::>
+and C<DBIx::> namespaces that perform the same function for C<LWP> and C<DBI>
+respectively.
+
=head1 METACLASS COMPATIBILITY AND MOOSE
Metaclass compatibility is a thorny subject. You should start by
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.
+when you set the superclasses for a class, in addition to the cases that
+C<Class::MOP> 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<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
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<for> Moose itself you'll want
-to put your extension in the C<MooseX::> namespace. This namespace is
-specifically for extensions that make Moose better or different in some
-fundamental way. It is traditionally B<not> for a package that just happens
-to use Moose. This namespace follows from the examples of the C<LWPx::>
-and C<DBIx::> namespaces that perform the same function for C<LWP> and C<DBI>
-respectively.
-
=head1 CAVEATS
=over 4
=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.
projects / gitmo/Moose.git / blobdiff