1Moose(3) User Contributed Perl Documentation Moose(3)
2
6 Moose - A postmodern object system for Perl 5
7
9 package Point;
10 use Moose; # automatically turns on strict and warnings
11 has 'x' => (is => 'rw', isa => 'Int');
13 has 'y' => (is => 'rw', isa => 'Int');
14 sub clear {
16 my $self = shift;
17 $self->x(0);
18 $self->y(0);
19 }
20 package Point3D;
22 use Moose;
23 extends 'Point';
25 has 'z' => (is => 'rw', isa => 'Int');
27 after 'clear' => sub {
29 my $self = shift;
30 $self->z(0);
31 };
32
34 Moose is an extension of the Perl 5 object system.
35 The main goal of Moose is to make Perl 5 Object Oriented programming
37 easier, more consistent and less tedious. With Moose you can to think
38 more about what you want to do and less about the mechanics of OOP.
39 Additionally, Moose is built on top of Class::MOP, which is a metaclass
41 system for Perl 5. This means that Moose not only makes building normal
42 Perl 5 objects better, but it provides the power of metaclass
43 programming as well.
44 New to Moose?
46 If you're new to Moose, the best place to start is the Moose::Manual
47 docs, followed by the Moose::Cookbook. The intro will show you what
48 Moose is, and how it makes Perl 5 OO better.
49 The cookbook recipes on Moose basics will get you up to speed with many
51 of Moose's features quickly. Once you have an idea of what Moose can
52 do, you can use the API documentation to get more detail on features
53 which interest you.
54 Moose Extensions
56 The "MooseX::" namespace is the official place to find Moose
57 extensions. These extensions can be found on the CPAN. The easiest
58 way to find them is to search for them
59 (<http://search.cpan.org/search?query=MooseX::>), or to examine
60 Task::Moose which aims to keep an up-to-date, easily installable list
61 of Moose extensions.
62
64 Much of the Moose documentation has been translated into other
65 languages.
66 Japanese
68 Japanese docs can be found at
69 http://perldoc.perlassociation.org/pod/Moose-Doc-JA/index.html
70 <http://perldoc.perlassociation.org/pod/Moose-Doc-JA/index.html>.
71 The source POD files can be found in GitHub:
72 http://github.com/jpa/Moose-Doc-JA <http://github.com/jpa/Moose-
73 Doc-JA>
74
76 Moose makes every attempt to provide as much convenience as possible
77 during class construction/definition, but still stay out of your way if
78 you want it to. Here are a few items to note when building classes with
79 Moose.
80 Unless specified with "extends", any class which uses Moose will
82 inherit from Moose::Object.
83 Moose will also manage all attributes (including inherited ones) that
85 are defined with "has". And (assuming you call "new", which is
86 inherited from Moose::Object) this includes properly initializing all
87 instance slots, setting defaults where appropriate, and performing any
88 type constraint checking or coercion.
89
91 Moose provides a number of methods to all your classes, mostly through
92 the inheritance of Moose::Object. There is however, one exception.
93 meta
95 This is a method which provides access to the current class's
96 metaclass.
97
99 Moose will export a number of functions into the class's namespace
100 which may then be used to set up the class. These functions all work
101 directly on the current class.
102 extends (@superclasses)
104 This function will set the superclass(es) for the current class.
105 This approach is recommended instead of "use base", because "use
107 base" actually "push"es onto the class's @ISA, whereas "extends"
108 will replace it. This is important to ensure that classes which do
109 not have superclasses still properly inherit from Moose::Object.
110 Each superclass can be followed by a hash reference with options.
112 Currently, only -version is recognized:
113 extends 'My::Parent' => { -version => 0.01 },
115 'My::OtherParent' => { -version => 0.03 };
116 An exception will be thrown if the version requirements are not
118 satisfied.
119 with (@roles)
121 This will apply a given set of @roles to the local class.
122 Like with "extends", each specified role can be followed by a hash
124 reference with a -version option:
125 with 'My::Role' => { -version => 0.32 },
127 'My::Otherrole' => { -version => 0.23 };
128 The specified version requirements must be satisfied, otherwise an
130 exception will be thrown.
131 If your role takes options or arguments, they can be passed along
133 in the hash reference as well.
134 has $name|@$names => %options
136 This will install an attribute of a given $name into the current
137 class. If the first parameter is an array reference, it will create
138 an attribute for every $name in the list. The %options are the same
139 as those provided by Class::MOP::Attribute, in addition to the list
140 below which are provided by Moose (Moose::Meta::Attribute to be
141 more specific):
142 is => 'rw'|'ro'
144 The is option accepts either rw (for read/write) or ro (for
145 read only). These will create either a read/write accessor or a
146 read-only accessor respectively, using the same name as the
147 $name of the attribute.
148 If you need more control over how your accessors are named, you
150 can use the reader, writer and accessor options inherited from
151 Class::MOP::Attribute, however if you use those, you won't need
152 the is option.
153 isa => $type_name
155 The isa option uses Moose's type constraint facilities to set
156 up runtime type checking for this attribute. Moose will perform
157 the checks during class construction, and within any accessors.
158 The $type_name argument must be a string. The string may be
159 either a class name or a type defined using Moose's type
160 definition features. (Refer to Moose::Util::TypeConstraints for
161 information on how to define a new type, and how to retrieve
162 type meta-data).
163 coerce => (1|0)
165 This will attempt to use coercion with the supplied type
166 constraint to change the value passed into any accessors or
167 constructors. You must have supplied a type constraint in order
168 for this to work. See Moose::Cookbook::Basics::Recipe5 for an
169 example.
170 does => $role_name
172 This will accept the name of a role which the value stored in
173 this attribute is expected to have consumed.
174 required => (1|0)
176 This marks the attribute as being required. This means a value
177 must be supplied during class construction, or the attribute
178 must be lazy and have either a default or a builder. Note that
179 c<required> does not say anything about the attribute's value,
180 which can be "undef".
181 weak_ref => (1|0)
183 This will tell the class to store the value of this attribute
184 as a weakened reference. If an attribute is a weakened
185 reference, it cannot also be coerced.
186 lazy => (1|0)
188 This will tell the class to not create this slot until
189 absolutely necessary. If an attribute is marked as lazy it
190 must have a default supplied.
191 auto_deref => (1|0)
193 This tells the accessor to automatically dereference the value
194 of this attribute when called in list context. The accessor
195 will still return a reference when called in scalar context.
196 If this behavior isn't desirable, "elements" in
197 Moose::Meta::Attribute::Native::Trait::Array or "elements" in
198 Moose::Meta::Attribute::Native::Trait::Hash may be a better
199 choice. The auto_deref option is only legal if your isa option
200 is either "ArrayRef" or "HashRef".
201 trigger => $code
203 The trigger option is a CODE reference which will be called
204 after the value of the attribute is set. The CODE ref is passed
205 the instance itself, the updated value, and the original value
206 if the attribute was already set.
207 You can have a trigger on a read-only attribute.
209 NOTE: Triggers will only fire when you assign to the attribute,
211 either in the constructor, or using the writer. Default and
212 built values will not cause the trigger to be fired.
213 handles => ARRAY | HASH | REGEXP | ROLE | ROLETYPE | DUCKTYPE |
215 CODE
216 The handles option provides Moose classes with automated
217 delegation features. This is a pretty complex and powerful
218 option. It accepts many different option formats, each with its
219 own benefits and drawbacks.
220 NOTE: The class being delegated to does not need to be a Moose
222 based class, which is why this feature is especially useful
223 when wrapping non-Moose classes.
224 All handles option formats share the following traits:
226 You cannot override a locally defined method with a delegated
228 method; an exception will be thrown if you try. That is to say,
229 if you define "foo" in your class, you cannot override it with
230 a delegated "foo". This is almost never something you would
231 want to do, and if it is, you should do it by hand and not use
232 Moose.
233 You cannot override any of the methods found in Moose::Object,
235 or the "BUILD" and "DEMOLISH" methods. These will not throw an
236 exception, but will silently move on to the next method in the
237 list. My reasoning for this is that you would almost never want
238 to do this, since it usually breaks your class. As with
239 overriding locally defined methods, if you do want to do this,
240 you should do it manually, not with Moose.
241 You do not need to have a reader (or accessor) for the
243 attribute in order to delegate to it. Moose will create a means
244 of accessing the value for you, however this will be several
245 times less efficient then if you had given the attribute a
246 reader (or accessor) to use.
247 Below is the documentation for each option format:
249 "ARRAY"
251 This is the most common usage for handles. You basically
252 pass a list of method names to be delegated, and Moose will
253 install a delegation method for each one.
254 "HASH"
256 This is the second most common usage for handles. Instead
257 of a list of method names, you pass a HASH ref where each
258 key is the method name you want installed locally, and its
259 value is the name of the original method in the class being
260 delegated to.
261 This can be very useful for recursive classes like trees.
263 Here is a quick example (soon to be expanded into a
264 Moose::Cookbook recipe):
265 package Tree;
267 use Moose;
268 has 'node' => (is => 'rw', isa => 'Any');
270 has 'children' => (
272 is => 'ro',
273 isa => 'ArrayRef',
274 default => sub { [] }
275 );
276 has 'parent' => (
278 is => 'rw',
279 isa => 'Tree',
280 weak_ref => 1,
281 handles => {
282 parent_node => 'node',
283 siblings => 'children',
284 }
285 );
286 In this example, the Tree package gets "parent_node" and
288 "siblings" methods, which delegate to the "node" and
289 "children" methods (respectively) of the Tree instance
290 stored in the "parent" slot.
291 You may also use an array reference to curry arguments to
293 the original method.
294 has 'thing' => (
296 ...
297 handles => { set_foo => [ set => 'foo' ] },
298 );
299 # $self->set_foo(...) calls $self->thing->set('foo', ...)
301 The first element of the array reference is the original
303 method name, and the rest is a list of curried arguments.
304 "REGEXP"
306 The regexp option works very similar to the ARRAY option,
307 except that it builds the list of methods for you. It
308 starts by collecting all possible methods of the class
309 being delegated to, then filters that list using the regexp
310 supplied here.
311 NOTE: An isa option is required when using the regexp
313 option format. This is so that we can determine (at compile
314 time) the method list from the class. Without an isa this
315 is just not possible.
316 "ROLE" or "ROLETYPE"
318 With the role option, you specify the name of a role or a
319 role type whose "interface" then becomes the list of
320 methods to handle. The "interface" can be defined as; the
321 methods of the role and any required methods of the role.
322 It should be noted that this does not include any method
323 modifiers or generated attribute methods (which is
324 consistent with role composition).
325 "DUCKTYPE"
327 With the duck type option, you pass a duck type object
328 whose "interface" then becomes the list of methods to
329 handle. The "interface" can be defined as; the list of
330 methods passed to "duck_type" to create a duck type object.
331 For more information on "duck_type" please check
332 Moose::Util::TypeConstraints.
333 "CODE"
335 This is the option to use when you really want to do
336 something funky. You should only use it if you really know
337 what you are doing, as it involves manual metaclass
338 twiddling.
339 This takes a code reference, which should expect two
341 arguments. The first is the attribute meta-object this
342 handles is attached to. The second is the metaclass of the
343 class being delegated to. It expects you to return a hash
344 (not a HASH ref) of the methods you want mapped.
345 metaclass => $metaclass_name
347 This tells the class to use a custom attribute metaclass for
348 this particular attribute. Custom attribute metaclasses are
349 useful for extending the capabilities of the has keyword: they
350 are the simplest way to extend the MOP, but they are still a
351 fairly advanced topic and too much to cover here, see
352 Moose::Cookbook::Meta::Recipe1 for more information.
353 See "Metaclass and Trait Name Resolution" for details on how a
355 metaclass name is resolved to a class name.
356 traits => [ @role_names ]
358 This tells Moose to take the list of @role_names and apply them
359 to the attribute meta-object. This is very similar to the
360 metaclass option, but allows you to use more than one extension
361 at a time.
362 See "Metaclass and Trait Name Resolution" for details on how a
364 trait name is resolved to a role name.
365 Also see Moose::Cookbook::Meta::Recipe3 for a metaclass trait
367 example.
368 builder => Str
370 The value of this key is the name of the method that will be
371 called to obtain the value used to initialize the attribute.
372 See the builder option docs in Class::MOP::Attribute
373 and/or Moose::Cookbook::Basics::Recipe8 for more information.
374 default => SCALAR | CODE
376 The value of this key is the default value which will
377 initialize the attribute.
378 NOTE: If the value is a simple scalar (string or number), then
380 it can be just passed as is. However, if you wish to
381 initialize it with a HASH or ARRAY ref, then you need to wrap
382 that inside a CODE reference. See the default option docs in
383 Class::MOP::Attribute for more information.
384 clearer => Str
386 Creates a method allowing you to clear the value, see the
387 clearer option docs in Class::MOP::Attribute for more
388 information.
389 predicate => Str
391 Creates a method to perform a basic test to see if a value has
392 been set in the attribute, see the predicate option docs in
393 Class::MOP::Attribute for more information.
394 lazy_build => (0|1)
396 Automatically define lazy => 1 as well as builder =>
397 "_build_$attr", clearer => "clear_$attr', predicate =>
398 'has_$attr' unless they are already defined.
399 initializer => Str
401 This may be a method name (referring to a method on the class
402 with this attribute) or a CODE ref. The initializer is used to
403 set the attribute value on an instance when the attribute is
404 set during instance initialization (but not when the value is
405 being assigned to). See the initializer option docs in
406 Class::MOP::Attribute for more information.
407 documentation => $string
409 An arbitrary string that can be retrieved later by calling
410 "$attr->documentation".
411 has +$name => %options
413 This is variation on the normal attribute creator "has" which
414 allows you to clone and extend an attribute from a superclass or
415 from a role. Here is an example of the superclass usage:
416 package Foo;
418 use Moose;
419 has 'message' => (
421 is => 'rw',
422 isa => 'Str',
423 default => 'Hello, I am a Foo'
424 );
425 package My::Foo;
427 use Moose;
428 extends 'Foo';
430 has '+message' => (default => 'Hello I am My::Foo');
432 What is happening here is that My::Foo is cloning the "message"
434 attribute from its parent class Foo, retaining the "is => 'rw'" and
435 "isa => 'Str'" characteristics, but changing the value in
436 "default".
437 Here is another example, but within the context of a role:
439 package Foo::Role;
441 use Moose::Role;
442 has 'message' => (
444 is => 'rw',
445 isa => 'Str',
446 default => 'Hello, I am a Foo'
447 );
448 package My::Foo;
450 use Moose;
451 with 'Foo::Role';
453 has '+message' => (default => 'Hello I am My::Foo');
455 In this case, we are basically taking the attribute which the role
457 supplied and altering it within the bounds of this feature.
458 Note that you can only extend an attribute from either a superclass
460 or a role, you cannot extend an attribute in a role that composes
461 over an attribute from another role.
462 Aside from where the attributes come from (one from superclass, the
464 other from a role), this feature works exactly the same. This
465 feature is restricted somewhat, so as to try and force at least
466 some sanity into it. You are only allowed to change the following
467 attributes:
468 default
470 Change the default value of an attribute.
471 coerce
473 Change whether the attribute attempts to coerce a value passed
474 to it.
475 required
477 Change if the attribute is required to have a value.
478 documentation
480 Change the documentation string associated with the attribute.
481 lazy
483 Change if the attribute lazily initializes the slot.
484 isa You are allowed to change the type without restriction.
486 It is recommended that you use this freedom with caution. We
488 used to only allow for extension only if the type was a subtype
489 of the parent's type, but we felt that was too restrictive and
490 is better left as a policy decision.
491 handles
493 You are allowed to add a new "handles" definition, but you are
494 not allowed to change one.
495 builder
497 You are allowed to add a new "builder" definition, but you are
498 not allowed to change one.
499 metaclass
501 You are allowed to add a new "metaclass" definition, but you
502 are not allowed to change one.
503 traits
505 You are allowed to add additional traits to the "traits"
506 definition. These traits will be composed into the attribute,
507 but preexisting traits are not overridden, or removed.
508 before $name|@names|\@names|qr/.../ => sub { ... }
510 after $name|@names|\@names|qr/.../ => sub { ... }
511 around $name|@names|\@names|qr/.../ => sub { ... }
512 These three items are syntactic sugar for the before, after, and
513 around method modifier features that Class::MOP provides. More
514 information on these may be found in Moose::Manual::MethodModifiers
515 and the Class::MOP::Class documentation.
516 super
518 The keyword "super" is a no-op when called outside of an "override"
519 method. In the context of an "override" method, it will call the
520 next most appropriate superclass method with the same arguments as
521 the original method.
522 override ($name, &sub)
524 An "override" method is a way of explicitly saying "I am overriding
525 this method from my superclass". You can call "super" within this
526 method, and it will work as expected. The same thing can be
527 accomplished with a normal method call and the "SUPER::" pseudo-
528 package; it is really your choice.
529 inner
531 The keyword "inner", much like "super", is a no-op outside of the
532 context of an "augment" method. You can think of "inner" as being
533 the inverse of "super"; the details of how "inner" and "augment"
534 work is best described in the Moose::Cookbook::Basics::Recipe6.
535 augment ($name, &sub)
537 An "augment" method, is a way of explicitly saying "I am augmenting
538 this method from my superclass". Once again, the details of how
539 "inner" and "augment" work is best described in the
540 Moose::Cookbook::Basics::Recipe6.
541 confess
543 This is the "Carp::confess" function, and exported here because I
544 use it all the time.
545 blessed
547 This is the "Scalar::Util::blessed" function, it is exported here
548 because I use it all the time. It is highly recommended that this
549 is used instead of "ref" anywhere you need to test for an object's
550 class name.
551
553 When you use Moose, you can specify which metaclass to use:
554 use Moose -metaclass => 'My::Meta::Class';
556 You can also specify traits which will be applied to your metaclass:
558 use Moose -traits => 'My::Trait';
560 This is very similar to the attribute traits feature. When you do this,
562 your class's "meta" object will have the specified traits applied to
563 it. See "Metaclass and Trait Name Resolution" for more details.
564 Metaclass and Trait Name Resolution
566 By default, when given a trait name, Moose simply tries to load a class
567 of the same name. If such a class does not exist, it then looks for for
568 a class matching Moose::Meta::$type::Custom::Trait::$trait_name. The
569 $type variable here will be one of Attribute or Class, depending on
570 what the trait is being applied to.
571 If a class with this long name exists, Moose checks to see if it has
573 the method "register_implementation". This method is expected to return
574 the real class name of the trait. If there is no
575 "register_implementation" method, it will fall back to using
576 Moose::Meta::$type::Custom::Trait::$trait as the trait name.
577 The lookup method for metaclasses is the same, except that it looks for
579 a class matching Moose::Meta::$type::Custom::$metaclass_name.
580 If all this is confusing, take a look at
582 Moose::Cookbook::Meta::Recipe3, which demonstrates how to create an
583 attribute trait.
584
586 unimport
587 Moose offers a way to remove the keywords it exports, through the
588 "unimport" method. You simply have to say "no Moose" at the bottom of
589 your code for this to work. Here is an example:
590 package Person;
592 use Moose;
593 has 'first_name' => (is => 'rw', isa => 'Str');
595 has 'last_name' => (is => 'rw', isa => 'Str');
596 sub full_name {
598 my $self = shift;
599 $self->first_name . ' ' . $self->last_name
600 }
601 no Moose; # keywords are removed from the Person package
603
605 To learn more about extending Moose, we recommend checking out the
606 "Extending" recipes in the Moose::Cookbook, starting with
607 Moose::Cookbook::Extending::Recipe1, which provides an overview of all
608 the different ways you might extend Moose.
609 Moose->init_meta(for_class => $class, base_class => $baseclass, metaclass
611 => $metaclass)
612 The "init_meta" method sets up the metaclass object for the class
613 specified by "for_class". This method injects a a "meta" accessor into
614 the class so you can get at this object. It also sets the class's
615 superclass to "base_class", with Moose::Object as the default.
616 "init_meta" returns the metaclass object for $class.
618 You can specify an alternate metaclass with the "metaclass" option.
620 For more detail on this topic, see Moose::Cookbook::Extending::Recipe2.
622 This method used to be documented as a function which accepted
624 positional parameters. This calling style will still work for backwards
625 compatibility, but is deprecated.
626 import
628 Moose's "import" method supports the Sub::Exporter form of "{into =>
629 $pkg}" and "{into_level => 1}".
630 NOTE: Doing this is more or less deprecated. Use Moose::Exporter
632 instead, which lets you stack multiple "Moose.pm"-alike modules sanely.
633 It handles getting the exported functions into the right place for you.
634 throw_error
636 An alias for "confess", used by internally by Moose.
637 The MooseX:: namespace
639 Generally if you're writing an extension for Moose itself you'll want
640 to put your extension in the "MooseX::" namespace. This namespace is
641 specifically for extensions that make Moose better or different in some
642 fundamental way. It is traditionally not for a package that just
643 happens to use Moose. This namespace follows from the examples of the
644 "LWPx::" and "DBIx::" namespaces that perform the same function for
645 "LWP" and "DBI" respectively.
646
648 Metaclass compatibility is a thorny subject. You should start by
649 reading the "About Metaclass compatibility" section in the "Class::MOP"
650 docs.
651 Moose will attempt to resolve a few cases of metaclass incompatibility
653 when you set the superclasses for a class, in addition to the cases
654 that "Class::MOP" handles.
655 Moose tries to determine if the metaclasses only "differ by roles".
657 This means that the parent and child's metaclass share a common
658 ancestor in their respective hierarchies, and that the subclasses under
659 the common ancestor are only different because of role applications.
660 This case is actually fairly common when you mix and match various
661 "MooseX::*" modules, many of which apply roles to the metaclass.
662 If the parent and child do differ by roles, Moose replaces the
664 metaclass in the child with a newly created metaclass. This metaclass
665 is a subclass of the parent's metaclass, does all of the roles that the
666 child's metaclass did before being replaced. Effectively, this means
667 the new metaclass does all of the roles done by both the parent's and
668 child's original metaclasses.
669 Ultimately, this is all transparent to you except in the case of an
671 unresolvable conflict.
672
674 ยท It should be noted that "super" and "inner" cannot be used in the
675 same method. However, they may be combined within the same class
676 hierarchy; see t/014_override_augment_inner_super.t for an example.
677 The reason for this is that "super" is only valid within a method
679 with the "override" modifier, and "inner" will never be valid
680 within an "override" method. In fact, "augment" will skip over any
681 "override" methods when searching for its appropriate "inner".
682 This might seem like a restriction, but I am of the opinion that
684 keeping these two features separate (yet interoperable) actually
685 makes them easy to use, since their behavior is then easier to
686 predict. Time will tell whether I am right or not (UPDATE: so far
687 so good).
688
690 We offer both a mailing list and a very active IRC channel.
691 The mailing list is moose@perl.org. You must be subscribed to send a
693 message. To subscribe, send an empty message to
694 moose-subscribe@perl.org
695 You can also visit us at "#moose" on <irc://irc.perl.org/#moose> This
697 channel is quite active, and questions at all levels (on Moose-related
698 topics ;) are welcome.
699
701 I blame Sam Vilain for introducing me to the insanity that is meta-
702 models.
703 I blame Audrey Tang for then encouraging my meta-model habit in #perl6.
704 Without Yuval "nothingmuch" Kogman this module would not be possible,
705 and it certainly wouldn't have this name ;P
706 The basis of the TypeContraints module was Rob Kinyon's idea
707 originally, I just ran with it.
708 Thanks to mst & chansen and the whole #moose posse for all the early
709 ideas/feature-requests/encouragement/bug-finding.
710 Thanks to David "Theory" Wheeler for meta-discussions and spelling
711 fixes.
712
714 <http://www.iinteractive.com/moose>
715 This is the official web home of Moose, it contains links to our
716 public git repository as well as links to a number of talks and
717 articles on Moose and Moose related technologies.
718 The Moose is flying, a tutorial by Randal Schwartz
720 Part 1 - <http://www.stonehenge.com/merlyn/LinuxMag/col94.html>
721 Part 2 - <http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
723 Several Moose extension modules in the "MooseX::" namespace.
725 See <http://search.cpan.org/search?query=MooseX::> for extensions.
726 Moose stats on ohloh.net - <http://www.ohloh.net/projects/moose>
728 Books
730 The Art of the MetaObject Protocol
731 I mention this in the Class::MOP docs too, this book was critical
732 in the development of both modules and is highly recommended.
733 Papers
735 http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf
736 <http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf>
737 This paper (suggested by lbr on #moose) was what lead to the
738 implementation of the "super"/"override" and "inner"/"augment"
739 features. If you really want to understand them, I suggest you read
740 this.
741
743 All complex software has bugs lurking in it, and this module is no
744 exception.
745 Please report any bugs to "bug-moose@rt.cpan.org", or through the web
747 interface at <http://rt.cpan.org>.
748 You can also discuss feature requests or possible bugs on the Moose
750 mailing list (moose@perl.org) or on IRC at <irc://irc.perl.org/#moose>.
751
753 We are very strict about what features we add to the Moose core,
754 especially the user-visible features. Instead we have made sure that
755 the underlying meta-system of Moose is as extensible as possible so
756 that you can add your own features easily.
757 That said, occasionally there is a feature needed in the meta-system to
759 support your planned extension, in which case you should either email
760 the mailing list (moose@perl.org) or join us on IRC at
761 <irc://irc.perl.org/#moose> to discuss. The Moose::Manual::Contributing
762 has more detail about how and when you can contribute.
763
765 Moose is an open project, there are at this point dozens of people who
766 have contributed, and can contribute. If you have added anything to the
767 Moose project you have a commit bit on this file and can add your name
768 to the list.
769 CABAL
771 However there are only a few people with the rights to release a new
772 version of Moose. The Moose Cabal are the people to go to with
773 questions regarding the wider purview of Moose, and help out
774 maintaining not just the code but the community as well.
775 Stevan (stevan) Little <stevan@iinteractive.com>
777 Jesse (doy) Luehrs <doy at tozt dot net>
779 Yuval (nothingmuch) Kogman
781 Shawn (sartak) Moore <sartak@bestpractical.com>
783 Hans Dieter (confound) Pearcey <hdp@pobox.com>
785 Chris (perigrin) Prather
787 Florian Ragwitz <rafl@debian.org>
789 Dave (autarch) Rolsky <autarch@urth.org>
791 OTHER CONTRIBUTORS
793 Aankhen
794 Adam (Alias) Kennedy
796 Anders (Debolaz) Nor Berle
798 Nathan (kolibrie) Gray
800 Christian (chansen) Hansen
802 Eric (ewilhelm) Wilhelm
804 Guillermo (groditi) Roditi
806 Jess (castaway) Robinson
808 Matt (mst) Trout
810 Robert (phaylon) Sedlacek
812 Robert (rlb3) Boone
814 Scott (konobi) McWhirter
816 Shlomi (rindolf) Fish
818 Wallace (wreis) Reis
820 Jonathan (jrockway) Rockway
822 Piotr (dexter) Roszatycki
824 Sam (mugwump) Vilain
826 Cory (gphat) Watson
828 Dylan Hardison (doc fixes)
830 ... and many other #moose folks
832
834 Copyright 2006-2010 by Infinity Interactive, Inc.
835 <http://www.iinteractive.com>
837 This library is free software; you can redistribute it and/or modify it
839 under the same terms as Perl itself.
840perl v5.12.2 2010-08-28 Moose(3)