use 5.008;
-our $VERSION = '0.66';
+our $VERSION = '0.75_01';
$VERSION = eval $VERSION;
our $AUTHORITY = 'cpan:STEVAN';
use Scalar::Util 'blessed';
-use Carp 'confess', 'croak', 'cluck';
+use Carp 'confess';
use Moose::Exporter;
-use Class::MOP 0.76;
+use Class::MOP 0.82_01;
use Moose::Meta::Class;
use Moose::Meta::TypeConstraint;
}
sub throw_error {
- # FIXME This
+ # FIXME This
shift;
goto \&confess
}
sub extends {
my $class = shift;
- croak "Must derive at least one class" unless @_;
-
- my @supers = @_;
- foreach my $super (@supers) {
- Class::MOP::load_class($super);
- croak "You cannot inherit from a Moose Role ($super)"
- if $super->can('meta') &&
- blessed $super->meta &&
- $super->meta->isa('Moose::Meta::Role')
- }
-
-
+ Moose->throw_error("Must derive at least one class") unless @_;
# 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);
- $meta->superclasses(@supers);
+ Moose::Meta::Class->initialize($class)->superclasses(@_);
}
sub with {
sub has {
my $class = shift;
my $name = shift;
- croak 'Usage: has \'name\' => ( key => value, ... )' if @_ == 1;
+
+ Moose->throw_error('Usage: has \'name\' => ( key => value, ... )')
+ if @_ == 1;
+
my %options = ( definition_context => _caller_info(), @_ );
my $attrs = ( ref($name) eq 'ARRAY' ) ? $name : [ ($name) ];
Class::MOP::Class->initialize($class)->add_attribute( $_, %options ) for @$attrs;
Moose::Meta::Method::Accessor
Moose::Meta::Method::Constructor
Moose::Meta::Method::Destructor
- Moose::Meta::Method::Overriden
+ Moose::Meta::Method::Overridden
Moose::Meta::Method::Augmented
Moose::Meta::Role
=head2 New to Moose?
-If you're new to Moose, the best place to start is the L<Moose::Intro>
-docs, followed by the L<Moose::Cookbook>. The intro will show you what
-Moose is, and how it makes Perl 5 OO better.
+If you're new to Moose, the best place to start is the
+L<Moose::Manual> docs, followed by the L<Moose::Cookbook>. The intro
+will show you what Moose is, and how it makes Perl 5 OO better.
The cookbook recipes on Moose basics will get you up to speed with
many of Moose's features quickly. Once you have an idea of what Moose
=head1 PROVIDED METHODS
-Moose provides a number of methods to all your classes, mostly through the
+Moose provides a number of methods to all your classes, mostly through the
inheritance of L<Moose::Object>. There is however, one exception.
=over 4
=item B<with (@roles)>
-This will apply a given set of C<@roles> to the local class.
+This will apply a given set of C<@roles> to the local class.
=item B<has $name|@$names =E<gt> %options>
=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, the
-updated value and the attribute meta-object (this is for more advanced fiddling
-and can typically be ignored). You B<cannot> have a trigger on a read-only
-attribute.
+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. You B<cannot> have a trigger on
+a read-only attribute.
B<NOTE:> Triggers will only fire when you B<assign> to the attribute,
either in the constructor, or using the writer. Default and built values will
overriding locally defined methods, if you do want to do this, you should do it
manually, not with Moose.
-You do not I<need> to have a reader (or accessor) for the attribute in order
-to delegate to it. Moose will create a means of accessing the value for you,
-however this will be several times B<less> efficient then if you had given
+You do not I<need> to have a reader (or accessor) for the attribute in order
+to delegate to it. Moose will create a means of accessing the value for you,
+however this will be several times B<less> efficient then if you had given
the attribute a reader (or accessor) to use.
Below is the documentation for each option format:
This tells the class to use a custom attribute metaclass for this particular
attribute. Custom attribute metaclasses are useful for extending the
capabilities of the I<has> keyword: they are the simplest way to extend the MOP,
-but they are still a fairly advanced topic and too much to cover here, see
+but they are still a fairly advanced topic and too much to cover here, see
L<Moose::Cookbook::Meta::Recipe1> for more information.
The default behavior here is to just load C<$metaclass_name>; however, we also
=item I<traits =E<gt> [ @role_names ]>
-This tells Moose to take the list of C<@role_names> and apply them to the
-attribute meta-object. This is very similar to the I<metaclass> option, but
+This tells Moose to take the list of C<@role_names> and apply them to the
+attribute meta-object. This is very similar to the I<metaclass> option, but
allows you to use more than one extension at a time.
See L<TRAIT NAME RESOLUTION> for details on how a trait name is
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<builder
option docs in Class::MOP::Attribute|Class::MOP::Attribute/builder>
-for more information.
+ and/or L<Moose::Cookbook::Basics::Recipe9> for more information.
=item I<default> => SCALAR | CODE
=item B<has +$name =E<gt> %options>
This is variation on the normal attribute creator C<has> which allows you to
-clone and extend an attribute from a superclass or from a role. Here is an
+clone and extend an attribute from a superclass or from a role. Here is an
example of the superclass usage:
package Foo;
has '+message' => (default => 'Hello I am My::Foo');
-In this case, we are basically taking the attribute which the role supplied
-and altering it within the bounds of this feature.
+In this case, we are basically taking the attribute which the role supplied
+and altering it within the bounds of this feature.
-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
+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:
=over 4
=item I<isa>
-You I<are> allowed to change the type without restriction.
+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.
+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>
=item I<traits>
You are allowed to B<add> additional traits to the C<traits> definition.
-These traits will be composed into the attribute, but pre-existing traits
+These traits will be composed into the attribute, but preexisting traits
B<are not> overridden, or removed.
=back
=item B<confess>
This is the C<Carp::confess> function, and exported here because I use it
-all the time.
+all the time.
=item B<blessed>
=back
-=head1 METACLASS TRAITS
+=head1 METACLASS
+
+When you use Moose, you can specify which metaclass to use:
-When you use Moose, you can also specify traits which will be applied
-to your metaclass:
+ use Moose -metaclass => 'My::Meta::Class';
+
+You can also specify traits which will be applied to your metaclass:
use Moose -traits => 'My::Trait';
this, your class's C<meta> object will have the specified traits
applied to it. See L<TRAIT NAME RESOLUTION> for more details.
-=head1 TRAIT NAME RESOLUTION
+=head2 Trait Name Resolution
By default, when given a trait name, Moose simply tries to load a
class of the same name. If such a class does not exist, it then looks
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.
-You can specify an alternate metaclass with the C<metaclass> parameter.
+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>.
=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::>
+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.
=item L<http://www.iinteractive.com/moose>
-This is the official web home of Moose, it contains links to our public SVN repo
+This is the official web home of Moose, it contains links to our public SVN repository
as well as links to a number of talks and articles on Moose and Moose related
technologies.
=item The Art of the MetaObject Protocol
-I mention this in the L<Class::MOP> docs too, this book was critical in
+I mention this in the L<Class::MOP> docs too, this book was critical in
the development of both modules and is highly recommended.
=back
=head1 FEATURE REQUESTS
-We are very strict about what features we add to the Moose core, especially
-the user-visible features. Instead we have made sure that the underlying
-meta-system of Moose is as extensible as possible so that you can add your
-own features easily. That said, occasionally there is a feature needed in the
-meta-system to support your planned extension, in which case you should
-either email the mailing list or join us on irc at #moose to discuss.
+We are very strict about what features we add to the Moose core, especially
+the user-visible features. Instead we have made sure that the underlying
+meta-system of Moose is as extensible as possible so that you can add your
+own features easily. That said, occasionally there is a feature needed in the
+meta-system to support your planned extension, in which case you should
+either email the mailing list or join us on irc at #moose to discuss. The
+L<Moose::Manual::Contributing> has more detail about how and when you can
+contribute.
=head1 AUTHOR
-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
+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
-However there are only a few people with the rights to release a new version
+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.
Anders (Debolaz) Nor Berle
-Nathan (kolibre) Gray
+Nathan (kolibrie) Gray
Christian (chansen) Hansen
projects / gitmo/Moose.git / blobdiff