8 our $AUTHORITY = 'cpan:STEVAN';
10 use Scalar::Util 'blessed';
11 use Carp 'confess', 'croak', 'cluck';
17 use Moose::Meta::Class;
18 use Moose::Meta::TypeConstraint;
19 use Moose::Meta::TypeCoercion;
20 use Moose::Meta::Attribute;
21 use Moose::Meta::Instance;
23 use Moose::Meta::Role;
26 use Moose::Util::TypeConstraints;
32 croak "Must derive at least one class" unless @_;
35 foreach my $super (@supers) {
36 Class::MOP::load_class($super);
37 croak "You cannot inherit from a Moose Role ($super)"
38 if $super->can('meta') &&
39 blessed $super->meta &&
40 $super->meta->isa('Moose::Meta::Role')
45 # this checks the metaclass to make sure
46 # it is correct, sometimes it can get out
47 # of sync when the classes are being built
48 my $meta = $class->meta->_fix_metaclass_incompatability(@supers);
49 $meta->superclasses(@supers);
54 Moose::Util::apply_all_roles($class->meta, @_);
60 croak 'Usage: has \'name\' => ( key => value, ... )' if @_ == 1;
62 my $attrs = ( ref($name) eq 'ARRAY' ) ? $name : [ ($name) ];
63 $class->meta->add_attribute( $_, %options ) for @$attrs;
68 Moose::Util::add_method_modifier($class, 'before', \@_);
73 Moose::Util::add_method_modifier($class, 'after', \@_);
78 Moose::Util::add_method_modifier($class, 'around', \@_);
82 return unless our $SUPER_BODY; $SUPER_BODY->(our @SUPER_ARGS);
87 my ( $name, $method ) = @_;
88 $class->meta->add_override_method_modifier( $name => $method );
93 our ( %INNER_BODY, %INNER_ARGS );
95 if ( my $body = $INNER_BODY{$pkg} ) {
96 my @args = @{ $INNER_ARGS{$pkg} };
97 local $INNER_ARGS{$pkg};
98 local $INNER_BODY{$pkg};
99 return $body->(@args);
107 my ( $name, $method ) = @_;
108 $class->meta->add_augment_method_modifier( $name => $method );
113 cluck "The make_immutable keyword has been deprecated, " .
114 "please go back to __PACKAGE__->meta->make_immutable\n";
115 $class->meta->make_immutable(@_);
118 my $exporter = Moose::Exporter->build_import_methods(
120 qw( extends with has before after around override augment make_immutable )
125 \&Scalar::Util::blessed,
130 # This used to be called as a function. This hack preserves
131 # backwards compatibility.
132 if ( $_[0] ne __PACKAGE__ ) {
133 return __PACKAGE__->init_meta(
143 my $class = $args{for_class}
144 or confess "Cannot call init_meta without specifying a for_class";
145 my $base_class = $args{base_class} || 'Moose::Object';
146 my $metaclass = $args{metaclass} || 'Moose::Meta::Class';
149 "The Metaclass $metaclass must be a subclass of Moose::Meta::Class."
150 unless $metaclass->isa('Moose::Meta::Class');
152 # make a subtype for each Moose class
154 unless find_type_constraint($class);
157 if ( $class->can('meta') ) {
159 # this is the case where the metaclass pragma
160 # was used before the 'use Moose' statement to
161 # override a specific class
162 $meta = $class->meta();
163 ( blessed($meta) && $meta->isa('Moose::Meta::Class') )
164 || confess "You already have a &meta function, but it does not return a Moose::Meta::Class";
168 # this is broken currently, we actually need
169 # to allow the possiblity of an inherited
170 # meta, which will not be visible until the
171 # user 'extends' first. This needs to have
172 # more intelligence to it
173 $meta = $metaclass->initialize($class);
176 # re-initialize so it inherits properly
177 $metaclass->initialize( blessed( $_[0] ) || $_[0] );
182 # make sure they inherit from Moose::Object
183 $meta->superclasses($base_class)
184 unless $meta->superclasses();
190 # This may be used in some older MooseX extensions.
192 goto &Moose::Exporter::_get_caller;
195 ## make 'em all immutable
197 $_->meta->make_immutable(
198 inline_constructor => 0,
199 inline_accessors => 1, # these are Class::MOP accessors, so they need inlining
202 'Moose::Meta::Attribute',
203 'Moose::Meta::Class',
204 'Moose::Meta::Instance',
206 'Moose::Meta::TypeConstraint',
207 'Moose::Meta::TypeConstraint::Union',
208 'Moose::Meta::TypeConstraint::Parameterized',
209 'Moose::Meta::TypeCoercion',
211 'Moose::Meta::Method',
212 'Moose::Meta::Method::Accessor',
213 'Moose::Meta::Method::Constructor',
214 'Moose::Meta::Method::Destructor',
215 'Moose::Meta::Method::Overriden',
218 'Moose::Meta::Role::Method',
219 'Moose::Meta::Role::Method::Required',
230 Moose - A postmodern object system for Perl 5
235 use Moose; # automatically turns on strict and warnings
237 has 'x' => (is => 'rw', isa => 'Int');
238 has 'y' => (is => 'rw', isa => 'Int');
251 has 'z' => (is => 'rw', isa => 'Int');
253 after 'clear' => sub {
260 Moose is an extension of the Perl 5 object system.
262 The main goal of Moose is to make Perl 5 Object Oriented programming
263 easier, more consistent and less tedious. With Moose you can to think
264 more about what you want to do and less about the mechanics of OOP.
266 Additionally, Moose is built on top of L<Class::MOP>, which is a
267 metaclass system for Perl 5. This means that Moose not only makes
268 building normal Perl 5 objects better, but it provides the power of
269 metaclass programming as well.
271 =head2 Moose Extensions
273 The C<MooseX::> namespace is the official place to find Moose extensions.
274 These extensions can be found on the CPAN. The easiest way to find them
275 is to search for them (L<http://search.cpan.org/search?query=MooseX::>),
276 or to examine L<Task::Moose> which aims to keep an up-to-date, easily
277 installable list of Moose extensions.
279 =head1 BUILDING CLASSES WITH MOOSE
281 Moose makes every attempt to provide as much convenience as possible during
282 class construction/definition, but still stay out of your way if you want it
283 to. Here are a few items to note when building classes with Moose.
285 Unless specified with C<extends>, any class which uses Moose will
286 inherit from L<Moose::Object>.
288 Moose will also manage all attributes (including inherited ones) that are
289 defined with C<has>. And (assuming you call C<new>, which is inherited from
290 L<Moose::Object>) this includes properly initializing all instance slots,
291 setting defaults where appropriate, and performing any type constraint checking
294 =head1 PROVIDED METHODS
296 Moose provides a number of methods to all your classes, mostly through the
297 inheritance of L<Moose::Object>. There is however, one exception.
303 This is a method which provides access to the current class's metaclass.
307 =head1 EXPORTED FUNCTIONS
309 Moose will export a number of functions into the class's namespace which
310 may then be used to set up the class. These functions all work directly
311 on the current class.
315 =item B<extends (@superclasses)>
317 This function will set the superclass(es) for the current class.
319 This approach is recommended instead of C<use base>, because C<use base>
320 actually C<push>es onto the class's C<@ISA>, whereas C<extends> will
321 replace it. This is important to ensure that classes which do not have
322 superclasses still properly inherit from L<Moose::Object>.
324 =item B<with (@roles)>
326 This will apply a given set of C<@roles> to the local class.
328 =item B<has $name =E<gt> %options>
330 This will install an attribute of a given C<$name> into the current class.
331 The C<%options> are the same as those provided by
332 L<Class::MOP::Attribute>, in addition to the list below which are provided
333 by Moose (L<Moose::Meta::Attribute> to be more specific):
337 =item I<is =E<gt> 'rw'|'ro'>
339 The I<is> option accepts either I<rw> (for read/write) or I<ro> (for read
340 only). These will create either a read/write accessor or a read-only
341 accessor respectively, using the same name as the C<$name> of the attribute.
343 If you need more control over how your accessors are named, you can use the
344 I<reader>, I<writer> and I<accessor> options inherited from
345 L<Class::MOP::Attribute>, however if you use those, you won't need the I<is>
348 =item I<isa =E<gt> $type_name>
350 The I<isa> option uses Moose's type constraint facilities to set up runtime
351 type checking for this attribute. Moose will perform the checks during class
352 construction, and within any accessors. The C<$type_name> argument must be a
353 string. The string may be either a class name or a type defined using
354 Moose's type definition features. (Refer to L<Moose::Util::TypeConstraints>
355 for information on how to define a new type, and how to retrieve type meta-data).
357 =item I<coerce =E<gt> (1|0)>
359 This will attempt to use coercion with the supplied type constraint to change
360 the value passed into any accessors or constructors. You B<must> have supplied
361 a type constraint in order for this to work. See L<Moose::Cookbook::Basics::Recipe5>
364 =item I<does =E<gt> $role_name>
366 This will accept the name of a role which the value stored in this attribute
367 is expected to have consumed.
369 =item I<required =E<gt> (1|0)>
371 This marks the attribute as being required. This means a I<defined> value must be
372 supplied during class construction, and the attribute may never be set to
373 C<undef> with an accessor.
375 =item I<weak_ref =E<gt> (1|0)>
377 This will tell the class to store the value of this attribute as a weakened
378 reference. If an attribute is a weakened reference, it B<cannot> also be
381 =item I<lazy =E<gt> (1|0)>
383 This will tell the class to not create this slot until absolutely necessary.
384 If an attribute is marked as lazy it B<must> have a default supplied.
386 =item I<auto_deref =E<gt> (1|0)>
388 This tells the accessor whether to automatically dereference the value returned.
389 This is only legal if your C<isa> option is either C<ArrayRef> or C<HashRef>.
391 =item I<trigger =E<gt> $code>
393 The I<trigger> option is a CODE reference which will be called after the value of
394 the attribute is set. The CODE ref will be passed the instance itself, the
395 updated value and the attribute meta-object (this is for more advanced fiddling
396 and can typically be ignored). You B<cannot> have a trigger on a read-only
399 =item I<handles =E<gt> ARRAY | HASH | REGEXP | ROLE | CODE>
401 The I<handles> option provides Moose classes with automated delegation features.
402 This is a pretty complex and powerful option. It accepts many different option
403 formats, each with its own benefits and drawbacks.
405 B<NOTE:> The class being delegated to does not need to be a Moose based class,
406 which is why this feature is especially useful when wrapping non-Moose classes.
408 All I<handles> option formats share the following traits:
410 You cannot override a locally defined method with a delegated method; an
411 exception will be thrown if you try. That is to say, if you define C<foo> in
412 your class, you cannot override it with a delegated C<foo>. This is almost never
413 something you would want to do, and if it is, you should do it by hand and not
416 You cannot override any of the methods found in Moose::Object, or the C<BUILD>
417 and C<DEMOLISH> methods. These will not throw an exception, but will silently
418 move on to the next method in the list. My reasoning for this is that you would
419 almost never want to do this, since it usually breaks your class. As with
420 overriding locally defined methods, if you do want to do this, you should do it
421 manually, not with Moose.
423 You do not I<need> to have a reader (or accessor) for the attribute in order
424 to delegate to it. Moose will create a means of accessing the value for you,
425 however this will be several times B<less> efficient then if you had given
426 the attribute a reader (or accessor) to use.
428 Below is the documentation for each option format:
434 This is the most common usage for I<handles>. You basically pass a list of
435 method names to be delegated, and Moose will install a delegation method
440 This is the second most common usage for I<handles>. Instead of a list of
441 method names, you pass a HASH ref where each key is the method name you
442 want installed locally, and its value is the name of the original method
443 in the class being delegated to.
445 This can be very useful for recursive classes like trees. Here is a
446 quick example (soon to be expanded into a Moose::Cookbook recipe):
451 has 'node' => (is => 'rw', isa => 'Any');
456 default => sub { [] }
464 parent_node => 'node',
465 siblings => 'children',
469 In this example, the Tree package gets C<parent_node> and C<siblings> methods,
470 which delegate to the C<node> and C<children> methods (respectively) of the Tree
471 instance stored in the C<parent> slot.
475 The regexp option works very similar to the ARRAY option, except that it builds
476 the list of methods for you. It starts by collecting all possible methods of the
477 class being delegated to, then filters that list using the regexp supplied here.
479 B<NOTE:> An I<isa> option is required when using the regexp option format. This
480 is so that we can determine (at compile time) the method list from the class.
481 Without an I<isa> this is just not possible.
485 With the role option, you specify the name of a role whose "interface" then
486 becomes the list of methods to handle. The "interface" can be defined as; the
487 methods of the role and any required methods of the role. It should be noted
488 that this does B<not> include any method modifiers or generated attribute
489 methods (which is consistent with role composition).
493 This is the option to use when you really want to do something funky. You should
494 only use it if you really know what you are doing, as it involves manual
497 This takes a code reference, which should expect two arguments. The first is the
498 attribute meta-object this I<handles> is attached to. The second is the
499 metaclass of the class being delegated to. It expects you to return a hash (not
500 a HASH ref) of the methods you want mapped.
504 =item I<metaclass =E<gt> $metaclass_name>
506 This tells the class to use a custom attribute metaclass for this particular
507 attribute. Custom attribute metaclasses are useful for extending the
508 capabilities of the I<has> keyword: they are the simplest way to extend the MOP,
509 but they are still a fairly advanced topic and too much to cover here, see
510 L<Moose::Cookbook::Meta::Recipe1> for more information.
512 The default behavior here is to just load C<$metaclass_name>; however, we also
513 have a way to alias to a shorter name. This will first look to see if
514 B<Moose::Meta::Attribute::Custom::$metaclass_name> exists. If it does, Moose
515 will then check to see if that has the method C<register_implementation>, which
516 should return the actual name of the custom attribute metaclass. If there is no
517 C<register_implementation> method, it will fall back to using
518 B<Moose::Meta::Attribute::Custom::$metaclass_name> as the metaclass name.
520 =item I<traits =E<gt> [ @role_names ]>
522 This tells Moose to take the list of C<@role_names> and apply them to the
523 attribute meta-object. This is very similar to the I<metaclass> option, but
524 allows you to use more than one extension at a time.
526 See L<TRAIT NAME RESOLUTION> for details on how a trait name is
527 resolved to a class name.
529 Also see L<Moose::Cookbook::Meta::Recipe3> for a metaclass trait
534 =item B<has +$name =E<gt> %options>
536 This is variation on the normal attibute creator C<has> which allows you to
537 clone and extend an attribute from a superclass or from a role. Here is an
538 example of the superclass usage:
546 default => 'Hello, I am a Foo'
554 has '+message' => (default => 'Hello I am My::Foo');
556 What is happening here is that B<My::Foo> is cloning the C<message> attribute
557 from its parent class B<Foo>, retaining the C<is =E<gt> 'rw'> and C<isa =E<gt>
558 'Str'> characteristics, but changing the value in C<default>.
560 Here is another example, but within the context of a role:
568 default => 'Hello, I am a Foo'
576 has '+message' => (default => 'Hello I am My::Foo');
578 In this case, we are basically taking the attribute which the role supplied
579 and altering it within the bounds of this feature.
581 Aside from where the attributes come from (one from superclass, the other
582 from a role), this feature works exactly the same. This feature is restricted
583 somewhat, so as to try and force at least I<some> sanity into it. You are only
584 allowed to change the following attributes:
590 Change the default value of an attribute.
594 Change whether the attribute attempts to coerce a value passed to it.
598 Change if the attribute is required to have a value.
600 =item I<documentation>
602 Change the documentation string associated with the attribute.
606 Change if the attribute lazily initializes the slot.
610 You I<are> allowed to change the type without restriction.
612 It is recommended that you use this freedom with caution. We used to
613 only allow for extension only if the type was a subtype of the parent's
614 type, but we felt that was too restrictive and is better left as a
619 You are allowed to B<add> a new C<handles> definition, but you are B<not>
620 allowed to I<change> one.
624 You are allowed to B<add> a new C<builder> definition, but you are B<not>
625 allowed to I<change> one.
629 You are allowed to B<add> a new C<metaclass> definition, but you are
630 B<not> allowed to I<change> one.
634 You are allowed to B<add> additional traits to the C<traits> definition.
635 These traits will be composed into the attribute, but pre-existing traits
636 B<are not> overridden, or removed.
640 =item B<before $name|@names =E<gt> sub { ... }>
642 =item B<after $name|@names =E<gt> sub { ... }>
644 =item B<around $name|@names =E<gt> sub { ... }>
646 This three items are syntactic sugar for the before, after, and around method
647 modifier features that L<Class::MOP> provides. More information on these may be
648 found in the L<Class::MOP::Class documentation|Class::MOP::Class/"Method
653 The keyword C<super> is a no-op when called outside of an C<override> method. In
654 the context of an C<override> method, it will call the next most appropriate
655 superclass method with the same arguments as the original method.
657 =item B<override ($name, &sub)>
659 An C<override> method is a way of explicitly saying "I am overriding this
660 method from my superclass". You can call C<super> within this method, and
661 it will work as expected. The same thing I<can> be accomplished with a normal
662 method call and the C<SUPER::> pseudo-package; it is really your choice.
666 The keyword C<inner>, much like C<super>, is a no-op outside of the context of
667 an C<augment> method. You can think of C<inner> as being the inverse of
668 C<super>; the details of how C<inner> and C<augment> work is best described in
669 the L<Moose::Cookbook::Basics::Recipe6>.
671 =item B<augment ($name, &sub)>
673 An C<augment> method, is a way of explicitly saying "I am augmenting this
674 method from my superclass". Once again, the details of how C<inner> and
675 C<augment> work is best described in the L<Moose::Cookbook::Basics::Recipe6>.
679 This is the C<Carp::confess> function, and exported here because I use it
684 This is the C<Scalar::Util::blessed> function, it is exported here because I
685 use it all the time. It is highly recommended that this is used instead of
686 C<ref> anywhere you need to test for an object's class name.
690 =head1 METACLASS TRAITS
692 When you use Moose, you can also specify traits which will be applied
695 use Moose -traits => 'My::Trait';
697 This is very similar to the attribute traits feature. When you do
698 this, your class's C<meta> object will have the specified traits
699 applied to it. See L<TRAIT NAME RESOLUTION> for more details.
701 =head1 TRAIT NAME RESOLUTION
703 By default, when given a trait name, Moose simply tries to load a
704 class of the same name. If such a class does not exist, it then looks
705 for for a class matching
706 B<Moose::Meta::$type::Custom::Trait::$trait_name>. The C<$type>
707 variable here will be one of B<Attribute> or B<Class>, depending on
708 what the trait is being applied to.
710 If a class with this long name exists, Moose checks to see if it has
711 the method C<register_implementation>. This method is expected to
712 return the I<real> class name of the trait. If there is no
713 C<register_implementation> method, it will fall back to using
714 B<Moose::Meta::$type::Custom::Trait::$trait> as the trait name.
716 If all this is confusing, take a look at
717 L<Moose::Cookbook::Meta::Recipe3>, which demonstrates how to create an
720 =head1 UNIMPORTING FUNCTIONS
724 Moose offers a way to remove the keywords it exports, through the C<unimport>
725 method. You simply have to say C<no Moose> at the bottom of your code for this
726 to work. Here is an example:
731 has 'first_name' => (is => 'rw', isa => 'Str');
732 has 'last_name' => (is => 'rw', isa => 'Str');
736 $self->first_name . ' ' . $self->last_name
739 no Moose; # keywords are removed from the Person package
741 =head1 EXTENDING AND EMBEDDING MOOSE
743 Moose also offers some options for extending or embedding it into your
744 own framework. There are several things you might want to do as part
745 of such a framework. First, you probably want to export Moose's sugar
746 functions (C<has>, C<extends>, etc) for users of the
747 framework. Second, you may want to provide additional sugar of your
748 own. Third, you may want to provide your own object base class instead
749 of L<Moose::Object>, and/or your own metaclass class instead of
750 L<Moose::Meta::Class>.
752 The exporting needs can be asily satisfied by using
753 L<Moose::Exporter>, which is what C<Moose.pm> itself uses for
754 exporting. L<Moose::Exporter> lets you "export like Moose".
756 If you define an C<init_meta> method in a module that uses
757 L<Moose::Exporter>, then this method will be called I<before>
758 C<Moose.pm>'s own C<init_meta>. This gives you a chance to provide an
759 alternate object base class or metaclass class.
761 Here is a simple example:
768 use Moose (); # no need to get Moose's exports
771 Moose::Exporter->build_import_methods( also => 'Moose' );
775 return Moose->init_meta( @_, base_class => 'MyFramework::Base' );
778 In this example, any class that includes C<use MyFramework> will get
779 all of C<Moose.pm>'s sugar functions, and will have their superclass
780 set to C<MyFramework::Base>.
782 Additionally, that class can include C<no MyFramework> to unimport
784 =head2 B<< Moose->init_meta(for_class => $class, base_class => $baseclass, metaclass => $metaclass) >>
786 The C<init_meta> method sets up the metaclass object for the class
787 specified by C<for_class>. This method injects a a C<meta> accessor
788 into the class so you can get at this object. It also sets the class's
789 superclass to C<base_class>, with L<Moose::Object> as the default.
791 You can specify an alternate metaclass with the C<metaclass> parameter.
793 For more detail on this topic, see L<Moose::Cookbook::Extending::Recipe2>.
795 This method used to be documented as a function which accepted
796 positional parameters. This calling style will still work for
797 backwards compatibility.
801 Moose's C<import> method supports the L<Sub::Exporter> form of C<{into =E<gt> $pkg}>
802 and C<{into_level =E<gt> 1}>.
804 B<NOTE>: Doing this is more or less deprecated. Use L<Moose::Exporter>
805 instead, which lets you stack multiple C<Moose.pm>-alike modules
806 sanely. It handles getting the exported functions into the right place
815 It should be noted that C<super> and C<inner> B<cannot> be used in the same
816 method. However, they may be combined within the same class hierarchy; see
817 F<t/014_override_augment_inner_super.t> for an example.
819 The reason for this is that C<super> is only valid within a method
820 with the C<override> modifier, and C<inner> will never be valid within an
821 C<override> method. In fact, C<augment> will skip over any C<override> methods
822 when searching for its appropriate C<inner>.
824 This might seem like a restriction, but I am of the opinion that keeping these
825 two features separate (yet interoperable) actually makes them easy to use, since
826 their behavior is then easier to predict. Time will tell whether I am right or
827 not (UPDATE: so far so good).
831 It is important to note that we currently have no simple way of combining
832 multiple extended versions of Moose (see L<EXTENDING AND EMBEDDING MOOSE> above),
833 and that in many cases they will conflict with one another. We are working on
834 developing a way around this issue, but in the meantime, you have been warned.
840 In case you are still asking yourself "Why do I need this?", then this
841 section is for you. This used to be part of the main DESCRIPTION, but
842 I think Moose no longer actually needs justification, so it is included
843 (read: buried) here for those who are still not convinced.
847 =item Another object system!?!?
849 Yes, I know there has been an explosion recently of new ways to
850 build objects in Perl 5, most of them based on inside-out objects
851 and other such things. Moose is different because it is not a new
852 object system for Perl 5, but instead an extension of the existing
855 Moose is built on top of L<Class::MOP>, which is a metaclass system
856 for Perl 5. This means that Moose not only makes building normal
857 Perl 5 objects better, but it also provides the power of metaclass
860 =item Is this for real? Or is this just an experiment?
862 Moose is I<based> on the prototypes and experiments I did for the Perl 6
863 meta-model. However, Moose is B<NOT> an experiment/prototype; it is for B<real>.
865 =item Is this ready for use in production?
867 Yes, I believe that it is.
869 Moose has been used successfully in production environemnts by several people
870 and companies (including the one I work for). There are Moose applications
871 which have been in production with little or no issue now for well over two years.
872 I consider it highly stable and we are commited to keeping it stable.
874 Of course, in the end, you need to make this call yourself. If you have
875 any questions or concerns, please feel free to email me, or even the list
876 or just stop by #moose and ask away.
878 =item Is Moose just Perl 6 in Perl 5?
880 No. While Moose is very much inspired by Perl 6, it is not itself Perl 6.
881 Instead, it is an OO system for Perl 5. I built Moose because I was tired of
882 writing the same old boring Perl 5 OO code, and drooling over Perl 6 OO. So
883 instead of switching to Ruby, I wrote Moose :)
885 =item Wait, I<post> modern, I thought it was just I<modern>?
887 So I was reading Larry Wall's talk from the 1999 Linux World entitled
888 "Perl, the first postmodern computer language" in which he talks about how
889 he picked the features for Perl because he thought they were cool and he
890 threw out the ones that he thought sucked. This got me thinking about how
891 we have done the same thing in Moose. For Moose, we have "borrowed" features
892 from Perl 6, CLOS (LISP), Smalltalk, Java, BETA, OCaml, Ruby and more, and
893 the bits we didn't like (cause they sucked) we tossed aside. So for this
894 reason (and a few others) I have re-dubbed Moose a I<postmodern> object system.
900 =head1 ACKNOWLEDGEMENTS
904 =item I blame Sam Vilain for introducing me to the insanity that is meta-models.
906 =item I blame Audrey Tang for then encouraging my meta-model habit in #perl6.
908 =item Without Yuval "nothingmuch" Kogman this module would not be possible,
909 and it certainly wouldn't have this name ;P
911 =item The basis of the TypeContraints module was Rob Kinyon's idea
912 originally, I just ran with it.
914 =item Thanks to mst & chansen and the whole #moose posse for all the
915 early ideas/feature-requests/encouragement/bug-finding.
917 =item Thanks to David "Theory" Wheeler for meta-discussions and spelling fixes.
925 =item L<http://www.iinteractive.com/moose>
927 This is the official web home of Moose, it contains links to our public SVN repo
928 as well as links to a number of talks and articles on Moose and Moose related
931 =item L<Moose::Cookbook> - How to cook a Moose
933 =item The Moose is flying, a tutorial by Randal Schwartz
935 Part 1 - L<http://www.stonehenge.com/merlyn/LinuxMag/col94.html>
937 Part 2 - L<http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
939 =item L<Class::MOP> documentation
941 =item The #moose channel on irc.perl.org
943 =item The Moose mailing list - moose@perl.org
945 =item Moose stats on ohloh.net - L<http://www.ohloh.net/projects/moose>
947 =item Several Moose extension modules in the C<MooseX::> namespace.
949 See L<http://search.cpan.org/search?query=MooseX::> for extensions.
957 =item The Art of the MetaObject Protocol
959 I mention this in the L<Class::MOP> docs too, this book was critical in
960 the development of both modules and is highly recommended.
968 =item L<http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf>
970 This paper (suggested by lbr on #moose) was what lead to the implementation
971 of the C<super>/C<override> and C<inner>/C<augment> features. If you really
972 want to understand them, I suggest you read this.
978 All complex software has bugs lurking in it, and this module is no
979 exception. If you find a bug please either email me, or add the bug
982 =head1 FEATURE REQUESTS
984 We are very strict about what features we add to the Moose core, especially
985 the user-visible features. Instead we have made sure that the underlying
986 meta-system of Moose is as extensible as possible so that you can add your
987 own features easily. That said, occasionally there is a feature needed in the
988 meta-system to support your planned extension, in which case you should
989 either email the mailing list or join us on irc at #moose to discuss.
993 Stevan Little E<lt>stevan@iinteractive.comE<gt>
995 B<with contributions from:>
1001 Anders (Debolaz) Nor Berle
1003 Nathan (kolibre) Gray
1005 Christian (chansen) Hansen
1007 Hans Dieter (confound) Pearcey
1009 Eric (ewilhelm) Wilhelm
1011 Guillermo (groditi) Roditi
1013 Jess (castaway) Robinson
1017 Robert (phaylon) Sedlacek
1021 Scott (konobi) McWhirter
1023 Shlomi (rindolf) Fish
1025 Yuval (nothingmuch) Kogman
1027 Chris (perigrin) Prather
1029 Wallace (wreis) Reis
1031 Jonathan (jrockway) Rockway
1033 Piotr (dexter) Roszatycki
1035 Sam (mugwump) Vilain
1037 Shawn (sartak) Moore
1039 ... and many other #moose folks
1041 =head1 COPYRIGHT AND LICENSE
1043 Copyright 2006-2008 by Infinity Interactive, Inc.
1045 L<http://www.iinteractive.com>
1047 This library is free software; you can redistribute it and/or modify
1048 it under the same terms as Perl itself.