use 5.008;
-our $VERSION = '0.93_02';
+our $VERSION = '1.05';
$VERSION = eval $VERSION;
our $AUTHORITY = 'cpan:STEVAN';
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<trigger =E<gt> $code>
The I<trigger> 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<can> have a trigger on a read-only attribute.
either in the constructor, or using the writer. Default and built values will
B<not> cause the trigger to be fired.
-=item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | DUCKTYPE | CODE>
+=item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | ROLETYPE | DUCKTYPE | CODE>
The I<handles> option provides Moose classes with automated delegation features.
This is a pretty complex and powerful option. It accepts many different option
is so that we can determine (at compile time) the method list from the class.
Without an I<isa> this is just not possible.
-=item C<ROLE>
+=item C<ROLE> or C<ROLETYPE>
-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<not> 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<role type|Moose::Meta::TypeConstraint::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<not> include any method modifiers or generated attribute methods (which
+is consistent with role composition).
=item C<DUCKTYPE>
=back
-=item B<before $name|@names =E<gt> sub { ... }>
+=item B<before $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
-=item B<after $name|@names =E<gt> sub { ... }>
+=item B<after $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
-=item B<around $name|@names =E<gt> sub { ... }>
+=item B<around $name|@names|\@names|qr/.../ =E<gt> sub { ... }>
These three items are syntactic sugar for the before, after, and around method
modifier features that L<Class::MOP> provides. More information on these may be
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.
-
-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.
+when you set the superclasses for a class, in addition to the cases that
+C<Class::MOP> handles.
-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
=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