9 our $VERSION = '0.55_03';
10 $VERSION = eval $VERSION;
11 our $AUTHORITY = 'cpan:STEVAN';
13 use Scalar::Util 'blessed';
14 use Carp 'confess', 'croak', 'cluck';
18 use Class::MOP 0.6407;
20 use Moose::Meta::Class;
21 use Moose::Meta::TypeConstraint;
22 use Moose::Meta::TypeCoercion;
23 use Moose::Meta::Attribute;
24 use Moose::Meta::Instance;
28 use Moose::Meta::Role;
29 use Moose::Meta::Role::Composite;
30 use Moose::Meta::Role::Application;
31 use Moose::Meta::Role::Application::RoleSummation;
32 use Moose::Meta::Role::Application::ToClass;
33 use Moose::Meta::Role::Application::ToRole;
34 use Moose::Meta::Role::Application::ToInstance;
35 use Moose::Meta::Role::Application::ToMetaclassInstance;
37 use Moose::Util::TypeConstraints;
43 croak "Must derive at least one class" unless @_;
46 foreach my $super (@supers) {
47 Class::MOP::load_class($super);
48 croak "You cannot inherit from a Moose Role ($super)"
49 if $super->can('meta') &&
50 blessed $super->meta &&
51 $super->meta->isa('Moose::Meta::Role')
56 # this checks the metaclass to make sure
57 # it is correct, sometimes it can get out
58 # of sync when the classes are being built
59 my $meta = Moose::Meta::Class->initialize($class)->_fix_metaclass_incompatability(@supers);
60 $meta->superclasses(@supers);
65 Moose::Util::apply_all_roles(Class::MOP::Class->initialize($class), @_);
71 croak 'Usage: has \'name\' => ( key => value, ... )' if @_ == 1;
73 my $attrs = ( ref($name) eq 'ARRAY' ) ? $name : [ ($name) ];
74 Class::MOP::Class->initialize($class)->add_attribute( $_, %options ) for @$attrs;
79 Moose::Util::add_method_modifier($class, 'before', \@_);
84 Moose::Util::add_method_modifier($class, 'after', \@_);
89 Moose::Util::add_method_modifier($class, 'around', \@_);
93 return unless our $SUPER_BODY; $SUPER_BODY->(our @SUPER_ARGS);
98 my ( $name, $method ) = @_;
99 Class::MOP::Class->initialize($class)->add_override_method_modifier( $name => $method );
104 our ( %INNER_BODY, %INNER_ARGS );
106 if ( my $body = $INNER_BODY{$pkg} ) {
107 my @args = @{ $INNER_ARGS{$pkg} };
108 local $INNER_ARGS{$pkg};
109 local $INNER_BODY{$pkg};
110 return $body->(@args);
118 my ( $name, $method ) = @_;
119 Class::MOP::Class->initialize($class)->add_augment_method_modifier( $name => $method );
124 cluck "The make_immutable keyword has been deprecated, " .
125 "please go back to __PACKAGE__->meta->make_immutable\n";
126 Class::MOP::Class->initialize($class)->make_immutable(@_);
129 Moose::Exporter->setup_import_methods(
131 qw( extends with has before after around override augment make_immutable )
136 \&Scalar::Util::blessed,
141 # This used to be called as a function. This hack preserves
142 # backwards compatibility.
143 if ( $_[0] ne __PACKAGE__ ) {
144 return __PACKAGE__->init_meta(
154 my $class = $args{for_class}
155 or confess "Cannot call init_meta without specifying a for_class";
156 my $base_class = $args{base_class} || 'Moose::Object';
157 my $metaclass = $args{metaclass} || 'Moose::Meta::Class';
160 "The Metaclass $metaclass must be a subclass of Moose::Meta::Class."
161 unless $metaclass->isa('Moose::Meta::Class');
163 # make a subtype for each Moose class
165 unless find_type_constraint($class);
169 if ( $meta = Class::MOP::get_metaclass_by_name($class) ) {
170 unless ( $meta->isa("Moose::Meta::Class") ) {
171 confess "$class already has a metaclass, but it does not inherit $metaclass ($meta)";
174 # no metaclass, no 'meta' method
176 # now we check whether our ancestors have metaclass, and if so borrow that
177 my ( undef, @isa ) = @{ $class->mro::get_linear_isa };
179 foreach my $ancestor ( @isa ) {
180 my $ancestor_meta = Class::MOP::get_metaclass_by_name($ancestor) || next;
182 my $ancestor_meta_class = ($ancestor_meta->is_immutable
183 ? $ancestor_meta->get_mutable_metaclass_name
184 : ref($ancestor_meta));
186 # if we have an ancestor metaclass that inherits $metaclass, we use
187 # that. This is like _fix_metaclass_incompatability, but we can do it now.
189 # the case of having an ancestry is not very common, but arises in
191 unless ( $metaclass->isa( $ancestor_meta_class ) ) {
192 if ( $ancestor_meta_class->isa($metaclass) ) {
193 $metaclass = $ancestor_meta_class;
198 $meta = $metaclass->initialize($class);
201 if ( $class->can('meta') ) {
202 # check 'meta' method
204 # it may be inherited
207 # this is the case where the metaclass pragma
208 # was used before the 'use Moose' statement to
209 # override a specific class
210 my $method_meta = $class->meta;
212 ( blessed($method_meta) && $method_meta->isa('Moose::Meta::Class') )
213 || confess "$class already has a &meta function, but it does not return a Moose::Meta::Class ($meta)";
215 $meta = $method_meta;
218 unless ( $meta->has_method("meta") ) { # don't overwrite
219 # also check for inherited non moose 'meta' method?
220 # FIXME also skip this if the user requested by passing an option
223 # re-initialize so it inherits properly
224 $metaclass->initialize( ref($_[0]) || $_[0] );
229 # make sure they inherit from Moose::Object
230 $meta->superclasses($base_class)
231 unless $meta->superclasses();
236 # This may be used in some older MooseX extensions.
238 goto &Moose::Exporter::_get_caller;
241 ## make 'em all immutable
243 $_->meta->make_immutable(
244 inline_constructor => 1,
245 constructor_name => "_new",
246 inline_accessors => 1, # these are Class::MOP accessors, so they need inlining
249 Moose::Meta::Attribute
251 Moose::Meta::Instance
253 Moose::Meta::TypeConstraint
254 Moose::Meta::TypeConstraint::Union
255 Moose::Meta::TypeConstraint::Parameterized
256 Moose::Meta::TypeConstraint::Parameterizable
257 Moose::Meta::TypeConstraint::Enum
258 Moose::Meta::TypeConstraint::Class
259 Moose::Meta::TypeConstraint::Role
260 Moose::Meta::TypeConstraint::Registry
261 Moose::Meta::TypeCoercion
262 Moose::Meta::TypeCoercion::Union
265 Moose::Meta::Method::Accessor
266 Moose::Meta::Method::Constructor
267 Moose::Meta::Method::Destructor
268 Moose::Meta::Method::Overriden
269 Moose::Meta::Method::Augmented
272 Moose::Meta::Role::Method
273 Moose::Meta::Role::Method::Required
275 Moose::Meta::Role::Composite
277 Moose::Meta::Role::Application
278 Moose::Meta::Role::Application::RoleSummation
279 Moose::Meta::Role::Application::ToClass
280 Moose::Meta::Role::Application::ToRole
281 Moose::Meta::Role::Application::ToInstance
282 Moose::Meta::Role::Application::ToMetaclassInstance
293 Moose - A postmodern object system for Perl 5
298 use Moose; # automatically turns on strict and warnings
300 has 'x' => (is => 'rw', isa => 'Int');
301 has 'y' => (is => 'rw', isa => 'Int');
314 has 'z' => (is => 'rw', isa => 'Int');
316 after 'clear' => sub {
323 Moose is an extension of the Perl 5 object system.
325 The main goal of Moose is to make Perl 5 Object Oriented programming
326 easier, more consistent and less tedious. With Moose you can to think
327 more about what you want to do and less about the mechanics of OOP.
329 Additionally, Moose is built on top of L<Class::MOP>, which is a
330 metaclass system for Perl 5. This means that Moose not only makes
331 building normal Perl 5 objects better, but it provides the power of
332 metaclass programming as well.
336 If you're new to Moose, the best place to start is the
337 L<Moose::Cookbook>. The recipes on Moose basics will get you up to
338 speed with many of Moose's features quickly. Once you have an idea of
339 what Moose can do, you can use the API documentation to get more
340 detail on features which interest you.
342 =head2 Moose Extensions
344 The C<MooseX::> namespace is the official place to find Moose extensions.
345 These extensions can be found on the CPAN. The easiest way to find them
346 is to search for them (L<http://search.cpan.org/search?query=MooseX::>),
347 or to examine L<Task::Moose> which aims to keep an up-to-date, easily
348 installable list of Moose extensions.
350 =head1 BUILDING CLASSES WITH MOOSE
352 Moose makes every attempt to provide as much convenience as possible during
353 class construction/definition, but still stay out of your way if you want it
354 to. Here are a few items to note when building classes with Moose.
356 Unless specified with C<extends>, any class which uses Moose will
357 inherit from L<Moose::Object>.
359 Moose will also manage all attributes (including inherited ones) that are
360 defined with C<has>. And (assuming you call C<new>, which is inherited from
361 L<Moose::Object>) this includes properly initializing all instance slots,
362 setting defaults where appropriate, and performing any type constraint checking
365 =head1 PROVIDED METHODS
367 Moose provides a number of methods to all your classes, mostly through the
368 inheritance of L<Moose::Object>. There is however, one exception.
374 This is a method which provides access to the current class's metaclass.
378 =head1 EXPORTED FUNCTIONS
380 Moose will export a number of functions into the class's namespace which
381 may then be used to set up the class. These functions all work directly
382 on the current class.
386 =item B<extends (@superclasses)>
388 This function will set the superclass(es) for the current class.
390 This approach is recommended instead of C<use base>, because C<use base>
391 actually C<push>es onto the class's C<@ISA>, whereas C<extends> will
392 replace it. This is important to ensure that classes which do not have
393 superclasses still properly inherit from L<Moose::Object>.
395 =item B<with (@roles)>
397 This will apply a given set of C<@roles> to the local class.
399 =item B<has $name =E<gt> %options>
401 This will install an attribute of a given C<$name> into the current class.
402 The C<%options> are the same as those provided by
403 L<Class::MOP::Attribute>, in addition to the list below which are provided
404 by Moose (L<Moose::Meta::Attribute> to be more specific):
408 =item I<is =E<gt> 'rw'|'ro'>
410 The I<is> option accepts either I<rw> (for read/write) or I<ro> (for read
411 only). These will create either a read/write accessor or a read-only
412 accessor respectively, using the same name as the C<$name> of the attribute.
414 If you need more control over how your accessors are named, you can use the
415 I<reader>, I<writer> and I<accessor> options inherited from
416 L<Class::MOP::Attribute>, however if you use those, you won't need the I<is>
419 =item I<isa =E<gt> $type_name>
421 The I<isa> option uses Moose's type constraint facilities to set up runtime
422 type checking for this attribute. Moose will perform the checks during class
423 construction, and within any accessors. The C<$type_name> argument must be a
424 string. The string may be either a class name or a type defined using
425 Moose's type definition features. (Refer to L<Moose::Util::TypeConstraints>
426 for information on how to define a new type, and how to retrieve type meta-data).
428 =item I<coerce =E<gt> (1|0)>
430 This will attempt to use coercion with the supplied type constraint to change
431 the value passed into any accessors or constructors. You B<must> have supplied
432 a type constraint in order for this to work. See L<Moose::Cookbook::Basics::Recipe5>
435 =item I<does =E<gt> $role_name>
437 This will accept the name of a role which the value stored in this attribute
438 is expected to have consumed.
440 =item I<required =E<gt> (1|0)>
442 This marks the attribute as being required. This means a I<defined> value must be
443 supplied during class construction, and the attribute may never be set to
444 C<undef> with an accessor.
446 =item I<weak_ref =E<gt> (1|0)>
448 This will tell the class to store the value of this attribute as a weakened
449 reference. If an attribute is a weakened reference, it B<cannot> also be
452 =item I<lazy =E<gt> (1|0)>
454 This will tell the class to not create this slot until absolutely necessary.
455 If an attribute is marked as lazy it B<must> have a default supplied.
457 =item I<auto_deref =E<gt> (1|0)>
459 This tells the accessor whether to automatically dereference the value returned.
460 This is only legal if your C<isa> option is either C<ArrayRef> or C<HashRef>.
462 =item I<trigger =E<gt> $code>
464 The I<trigger> option is a CODE reference which will be called after the value of
465 the attribute is set. The CODE ref will be passed the instance itself, the
466 updated value and the attribute meta-object (this is for more advanced fiddling
467 and can typically be ignored). You B<cannot> have a trigger on a read-only
470 =item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | CODE>
472 The I<handles> option provides Moose classes with automated delegation features.
473 This is a pretty complex and powerful option. It accepts many different option
474 formats, each with its own benefits and drawbacks.
476 B<NOTE:> The class being delegated to does not need to be a Moose based class,
477 which is why this feature is especially useful when wrapping non-Moose classes.
479 All I<handles> option formats share the following traits:
481 You cannot override a locally defined method with a delegated method; an
482 exception will be thrown if you try. That is to say, if you define C<foo> in
483 your class, you cannot override it with a delegated C<foo>. This is almost never
484 something you would want to do, and if it is, you should do it by hand and not
487 You cannot override any of the methods found in Moose::Object, or the C<BUILD>
488 and C<DEMOLISH> methods. These will not throw an exception, but will silently
489 move on to the next method in the list. My reasoning for this is that you would
490 almost never want to do this, since it usually breaks your class. As with
491 overriding locally defined methods, if you do want to do this, you should do it
492 manually, not with Moose.
494 You do not I<need> to have a reader (or accessor) for the attribute in order
495 to delegate to it. Moose will create a means of accessing the value for you,
496 however this will be several times B<less> efficient then if you had given
497 the attribute a reader (or accessor) to use.
499 Below is the documentation for each option format:
505 This is the most common usage for I<handles>. You basically pass a list of
506 method names to be delegated, and Moose will install a delegation method
511 This is the second most common usage for I<handles>. Instead of a list of
512 method names, you pass a HASH ref where each key is the method name you
513 want installed locally, and its value is the name of the original method
514 in the class being delegated to.
516 This can be very useful for recursive classes like trees. Here is a
517 quick example (soon to be expanded into a Moose::Cookbook recipe):
522 has 'node' => (is => 'rw', isa => 'Any');
527 default => sub { [] }
535 parent_node => 'node',
536 siblings => 'children',
540 In this example, the Tree package gets C<parent_node> and C<siblings> methods,
541 which delegate to the C<node> and C<children> methods (respectively) of the Tree
542 instance stored in the C<parent> slot.
546 The regexp option works very similar to the ARRAY option, except that it builds
547 the list of methods for you. It starts by collecting all possible methods of the
548 class being delegated to, then filters that list using the regexp supplied here.
550 B<NOTE:> An I<isa> option is required when using the regexp option format. This
551 is so that we can determine (at compile time) the method list from the class.
552 Without an I<isa> this is just not possible.
556 With the role option, you specify the name of a role whose "interface" then
557 becomes the list of methods to handle. The "interface" can be defined as; the
558 methods of the role and any required methods of the role. It should be noted
559 that this does B<not> include any method modifiers or generated attribute
560 methods (which is consistent with role composition).
564 This is the option to use when you really want to do something funky. You should
565 only use it if you really know what you are doing, as it involves manual
568 This takes a code reference, which should expect two arguments. The first is the
569 attribute meta-object this I<handles> is attached to. The second is the
570 metaclass of the class being delegated to. It expects you to return a hash (not
571 a HASH ref) of the methods you want mapped.
575 =item I<metaclass =E<gt> $metaclass_name>
577 This tells the class to use a custom attribute metaclass for this particular
578 attribute. Custom attribute metaclasses are useful for extending the
579 capabilities of the I<has> keyword: they are the simplest way to extend the MOP,
580 but they are still a fairly advanced topic and too much to cover here, see
581 L<Moose::Cookbook::Meta::Recipe1> for more information.
583 The default behavior here is to just load C<$metaclass_name>; however, we also
584 have a way to alias to a shorter name. This will first look to see if
585 B<Moose::Meta::Attribute::Custom::$metaclass_name> exists. If it does, Moose
586 will then check to see if that has the method C<register_implementation>, which
587 should return the actual name of the custom attribute metaclass. If there is no
588 C<register_implementation> method, it will fall back to using
589 B<Moose::Meta::Attribute::Custom::$metaclass_name> as the metaclass name.
591 =item I<traits =E<gt> [ @role_names ]>
593 This tells Moose to take the list of C<@role_names> and apply them to the
594 attribute meta-object. This is very similar to the I<metaclass> option, but
595 allows you to use more than one extension at a time.
597 See L<TRAIT NAME RESOLUTION> for details on how a trait name is
598 resolved to a class name.
600 Also see L<Moose::Cookbook::Meta::Recipe3> for a metaclass trait
605 =item B<has +$name =E<gt> %options>
607 This is variation on the normal attibute creator C<has> which allows you to
608 clone and extend an attribute from a superclass or from a role. Here is an
609 example of the superclass usage:
617 default => 'Hello, I am a Foo'
625 has '+message' => (default => 'Hello I am My::Foo');
627 What is happening here is that B<My::Foo> is cloning the C<message> attribute
628 from its parent class B<Foo>, retaining the C<is =E<gt> 'rw'> and C<isa =E<gt>
629 'Str'> characteristics, but changing the value in C<default>.
631 Here is another example, but within the context of a role:
639 default => 'Hello, I am a Foo'
647 has '+message' => (default => 'Hello I am My::Foo');
649 In this case, we are basically taking the attribute which the role supplied
650 and altering it within the bounds of this feature.
652 Aside from where the attributes come from (one from superclass, the other
653 from a role), this feature works exactly the same. This feature is restricted
654 somewhat, so as to try and force at least I<some> sanity into it. You are only
655 allowed to change the following attributes:
661 Change the default value of an attribute.
665 Change whether the attribute attempts to coerce a value passed to it.
669 Change if the attribute is required to have a value.
671 =item I<documentation>
673 Change the documentation string associated with the attribute.
677 Change if the attribute lazily initializes the slot.
681 You I<are> allowed to change the type without restriction.
683 It is recommended that you use this freedom with caution. We used to
684 only allow for extension only if the type was a subtype of the parent's
685 type, but we felt that was too restrictive and is better left as a
690 You are allowed to B<add> a new C<handles> definition, but you are B<not>
691 allowed to I<change> one.
695 You are allowed to B<add> a new C<builder> definition, but you are B<not>
696 allowed to I<change> one.
700 You are allowed to B<add> a new C<metaclass> definition, but you are
701 B<not> allowed to I<change> one.
705 You are allowed to B<add> additional traits to the C<traits> definition.
706 These traits will be composed into the attribute, but pre-existing traits
707 B<are not> overridden, or removed.
711 =item B<before $name|@names =E<gt> sub { ... }>
713 =item B<after $name|@names =E<gt> sub { ... }>
715 =item B<around $name|@names =E<gt> sub { ... }>
717 This three items are syntactic sugar for the before, after, and around method
718 modifier features that L<Class::MOP> provides. More information on these may be
719 found in the L<Class::MOP::Class documentation|Class::MOP::Class/"Method
724 The keyword C<super> is a no-op when called outside of an C<override> method. In
725 the context of an C<override> method, it will call the next most appropriate
726 superclass method with the same arguments as the original method.
728 =item B<override ($name, &sub)>
730 An C<override> method is a way of explicitly saying "I am overriding this
731 method from my superclass". You can call C<super> within this method, and
732 it will work as expected. The same thing I<can> be accomplished with a normal
733 method call and the C<SUPER::> pseudo-package; it is really your choice.
737 The keyword C<inner>, much like C<super>, is a no-op outside of the context of
738 an C<augment> method. You can think of C<inner> as being the inverse of
739 C<super>; the details of how C<inner> and C<augment> work is best described in
740 the L<Moose::Cookbook::Basics::Recipe6>.
742 =item B<augment ($name, &sub)>
744 An C<augment> method, is a way of explicitly saying "I am augmenting this
745 method from my superclass". Once again, the details of how C<inner> and
746 C<augment> work is best described in the L<Moose::Cookbook::Basics::Recipe6>.
750 This is the C<Carp::confess> function, and exported here because I use it
755 This is the C<Scalar::Util::blessed> function, it is exported here because I
756 use it all the time. It is highly recommended that this is used instead of
757 C<ref> anywhere you need to test for an object's class name.
761 =head1 METACLASS TRAITS
763 When you use Moose, you can also specify traits which will be applied
766 use Moose -traits => 'My::Trait';
768 This is very similar to the attribute traits feature. When you do
769 this, your class's C<meta> object will have the specified traits
770 applied to it. See L<TRAIT NAME RESOLUTION> for more details.
772 =head1 TRAIT NAME RESOLUTION
774 By default, when given a trait name, Moose simply tries to load a
775 class of the same name. If such a class does not exist, it then looks
776 for for a class matching
777 B<Moose::Meta::$type::Custom::Trait::$trait_name>. The C<$type>
778 variable here will be one of B<Attribute> or B<Class>, depending on
779 what the trait is being applied to.
781 If a class with this long name exists, Moose checks to see if it has
782 the method C<register_implementation>. This method is expected to
783 return the I<real> class name of the trait. If there is no
784 C<register_implementation> method, it will fall back to using
785 B<Moose::Meta::$type::Custom::Trait::$trait> as the trait name.
787 If all this is confusing, take a look at
788 L<Moose::Cookbook::Meta::Recipe3>, which demonstrates how to create an
791 =head1 UNIMPORTING FUNCTIONS
795 Moose offers a way to remove the keywords it exports, through the C<unimport>
796 method. You simply have to say C<no Moose> at the bottom of your code for this
797 to work. Here is an example:
802 has 'first_name' => (is => 'rw', isa => 'Str');
803 has 'last_name' => (is => 'rw', isa => 'Str');
807 $self->first_name . ' ' . $self->last_name
810 no Moose; # keywords are removed from the Person package
812 =head1 EXTENDING AND EMBEDDING MOOSE
814 Moose also offers some options for extending or embedding it into your
815 own framework. There are several things you might want to do as part
816 of such a framework. First, you probably want to export Moose's sugar
817 functions (C<has>, C<extends>, etc) for users of the
818 framework. Second, you may want to provide additional sugar of your
819 own. Third, you may want to provide your own object base class instead
820 of L<Moose::Object>, and/or your own metaclass class instead of
821 L<Moose::Meta::Class>.
823 The exporting needs can be asily satisfied by using
824 L<Moose::Exporter>, which is what C<Moose.pm> itself uses for
825 exporting. L<Moose::Exporter> lets you "export like Moose".
827 If you define an C<init_meta> method in a module that uses
828 L<Moose::Exporter>, then this method will be called I<before>
829 C<Moose.pm>'s own C<init_meta>. This gives you a chance to provide an
830 alternate object base class or metaclass class.
832 Here is a simple example:
839 use Moose (); # no need to get Moose's exports
842 Moose::Exporter->setup_import_methods( also => 'Moose' );
846 return Moose->init_meta( @_, base_class => 'MyFramework::Base' );
849 In this example, any class that includes C<use MyFramework> will get
850 all of C<Moose.pm>'s sugar functions, and will have their superclass
851 set to C<MyFramework::Base>.
853 Additionally, that class can include C<no MyFramework> to unimport
855 =head2 B<< Moose->init_meta(for_class => $class, base_class => $baseclass, metaclass => $metaclass) >>
857 The C<init_meta> method sets up the metaclass object for the class
858 specified by C<for_class>. This method injects a a C<meta> accessor
859 into the class so you can get at this object. It also sets the class's
860 superclass to C<base_class>, with L<Moose::Object> as the default.
862 You can specify an alternate metaclass with the C<metaclass> parameter.
864 For more detail on this topic, see L<Moose::Cookbook::Extending::Recipe2>.
866 This method used to be documented as a function which accepted
867 positional parameters. This calling style will still work for
868 backwards compatibility, but is deprecated.
872 Moose's C<import> method supports the L<Sub::Exporter> form of C<{into =E<gt> $pkg}>
873 and C<{into_level =E<gt> 1}>.
875 B<NOTE>: Doing this is more or less deprecated. Use L<Moose::Exporter>
876 instead, which lets you stack multiple C<Moose.pm>-alike modules
877 sanely. It handles getting the exported functions into the right place
886 It should be noted that C<super> and C<inner> B<cannot> be used in the same
887 method. However, they may be combined within the same class hierarchy; see
888 F<t/014_override_augment_inner_super.t> for an example.
890 The reason for this is that C<super> is only valid within a method
891 with the C<override> modifier, and C<inner> will never be valid within an
892 C<override> method. In fact, C<augment> will skip over any C<override> methods
893 when searching for its appropriate C<inner>.
895 This might seem like a restriction, but I am of the opinion that keeping these
896 two features separate (yet interoperable) actually makes them easy to use, since
897 their behavior is then easier to predict. Time will tell whether I am right or
898 not (UPDATE: so far so good).
902 It is important to note that we currently have no simple way of combining
903 multiple extended versions of Moose (see L<EXTENDING AND EMBEDDING MOOSE> above),
904 and that in many cases they will conflict with one another. We are working on
905 developing a way around this issue, but in the meantime, you have been warned.
911 In case you are still asking yourself "Why do I need this?", then this
912 section is for you. This used to be part of the main DESCRIPTION, but
913 I think Moose no longer actually needs justification, so it is included
914 (read: buried) here for those who are still not convinced.
918 =item Another object system!?!?
920 Yes, I know there has been an explosion recently of new ways to
921 build objects in Perl 5, most of them based on inside-out objects
922 and other such things. Moose is different because it is not a new
923 object system for Perl 5, but instead an extension of the existing
926 Moose is built on top of L<Class::MOP>, which is a metaclass system
927 for Perl 5. This means that Moose not only makes building normal
928 Perl 5 objects better, but it also provides the power of metaclass
931 =item Is this for real? Or is this just an experiment?
933 Moose is I<based> on the prototypes and experiments I did for the Perl 6
934 meta-model. However, Moose is B<NOT> an experiment/prototype; it is for B<real>.
936 =item Is this ready for use in production?
938 Yes, I believe that it is.
940 Moose has been used successfully in production environemnts by several people
941 and companies (including the one I work for). There are Moose applications
942 which have been in production with little or no issue now for well over two years.
943 I consider it highly stable and we are commited to keeping it stable.
945 Of course, in the end, you need to make this call yourself. If you have
946 any questions or concerns, please feel free to email me, or even the list
947 or just stop by #moose and ask away.
949 =item Is Moose just Perl 6 in Perl 5?
951 No. While Moose is very much inspired by Perl 6, it is not itself Perl 6.
952 Instead, it is an OO system for Perl 5. I built Moose because I was tired of
953 writing the same old boring Perl 5 OO code, and drooling over Perl 6 OO. So
954 instead of switching to Ruby, I wrote Moose :)
956 =item Wait, I<post> modern, I thought it was just I<modern>?
958 So I was reading Larry Wall's talk from the 1999 Linux World entitled
959 "Perl, the first postmodern computer language" in which he talks about how
960 he picked the features for Perl because he thought they were cool and he
961 threw out the ones that he thought sucked. This got me thinking about how
962 we have done the same thing in Moose. For Moose, we have "borrowed" features
963 from Perl 6, CLOS (LISP), Smalltalk, Java, BETA, OCaml, Ruby and more, and
964 the bits we didn't like (cause they sucked) we tossed aside. So for this
965 reason (and a few others) I have re-dubbed Moose a I<postmodern> object system.
971 =head1 ACKNOWLEDGEMENTS
975 =item I blame Sam Vilain for introducing me to the insanity that is meta-models.
977 =item I blame Audrey Tang for then encouraging my meta-model habit in #perl6.
979 =item Without Yuval "nothingmuch" Kogman this module would not be possible,
980 and it certainly wouldn't have this name ;P
982 =item The basis of the TypeContraints module was Rob Kinyon's idea
983 originally, I just ran with it.
985 =item Thanks to mst & chansen and the whole #moose posse for all the
986 early ideas/feature-requests/encouragement/bug-finding.
988 =item Thanks to David "Theory" Wheeler for meta-discussions and spelling fixes.
996 =item L<http://www.iinteractive.com/moose>
998 This is the official web home of Moose, it contains links to our public SVN repo
999 as well as links to a number of talks and articles on Moose and Moose related
1002 =item L<Moose::Cookbook> - How to cook a Moose
1004 =item The Moose is flying, a tutorial by Randal Schwartz
1006 Part 1 - L<http://www.stonehenge.com/merlyn/LinuxMag/col94.html>
1008 Part 2 - L<http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
1010 =item L<Class::MOP> documentation
1012 =item The #moose channel on irc.perl.org
1014 =item The Moose mailing list - moose@perl.org
1016 =item Moose stats on ohloh.net - L<http://www.ohloh.net/projects/moose>
1018 =item Several Moose extension modules in the C<MooseX::> namespace.
1020 See L<http://search.cpan.org/search?query=MooseX::> for extensions.
1028 =item The Art of the MetaObject Protocol
1030 I mention this in the L<Class::MOP> docs too, this book was critical in
1031 the development of both modules and is highly recommended.
1039 =item L<http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf>
1041 This paper (suggested by lbr on #moose) was what lead to the implementation
1042 of the C<super>/C<override> and C<inner>/C<augment> features. If you really
1043 want to understand them, I suggest you read this.
1049 All complex software has bugs lurking in it, and this module is no
1050 exception. If you find a bug please either email me, or add the bug
1053 =head1 FEATURE REQUESTS
1055 We are very strict about what features we add to the Moose core, especially
1056 the user-visible features. Instead we have made sure that the underlying
1057 meta-system of Moose is as extensible as possible so that you can add your
1058 own features easily. That said, occasionally there is a feature needed in the
1059 meta-system to support your planned extension, in which case you should
1060 either email the mailing list or join us on irc at #moose to discuss.
1064 Stevan Little E<lt>stevan@iinteractive.comE<gt>
1066 B<with contributions from:>
1070 Adam (Alias) Kennedy
1072 Anders (Debolaz) Nor Berle
1074 Nathan (kolibre) Gray
1076 Christian (chansen) Hansen
1078 Hans Dieter (confound) Pearcey
1080 Eric (ewilhelm) Wilhelm
1082 Guillermo (groditi) Roditi
1084 Jess (castaway) Robinson
1088 Robert (phaylon) Sedlacek
1092 Scott (konobi) McWhirter
1094 Shlomi (rindolf) Fish
1096 Yuval (nothingmuch) Kogman
1098 Chris (perigrin) Prather
1100 Wallace (wreis) Reis
1102 Jonathan (jrockway) Rockway
1104 Piotr (dexter) Roszatycki
1106 Sam (mugwump) Vilain
1108 Shawn (sartak) Moore
1110 ... and many other #moose folks
1112 =head1 COPYRIGHT AND LICENSE
1114 Copyright 2006-2008 by Infinity Interactive, Inc.
1116 L<http://www.iinteractive.com>
1118 This library is free software; you can redistribute it and/or modify
1119 it under the same terms as Perl itself.