1Moose(3) User Contributed Perl Documentation Moose(3)
2
6 Moose - A postmodern object system for Perl 5
7
9 version 2.2014
10
12 package Point;
13 use Moose; # automatically turns on strict and warnings
14 has 'x' => (is => 'rw', isa => 'Int');
16 has 'y' => (is => 'rw', isa => 'Int');
17 sub clear {
19 my $self = shift;
20 $self->x(0);
21 $self->y(0);
22 }
23 package Point3D;
25 use Moose;
26 extends 'Point';
28 has 'z' => (is => 'rw', isa => 'Int');
30 after 'clear' => sub {
32 my $self = shift;
33 $self->z(0);
34 };
35
37 Moose is an extension of the Perl 5 object system.
38 The main goal of Moose is to make Perl 5 Object Oriented programming
40 easier, more consistent, and less tedious. With Moose you can think
41 more about what you want to do and less about the mechanics of OOP.
42 Additionally, Moose is built on top of Class::MOP, which is a metaclass
44 system for Perl 5. This means that Moose not only makes building normal
45 Perl 5 objects better, but it provides the power of metaclass
46 programming as well.
47 New to Moose?
49 If you're new to Moose, the best place to start is the Moose::Manual
50 docs, followed by the Moose::Cookbook. The intro will show you what
51 Moose is, and how it makes Perl 5 OO better.
52 The cookbook recipes on Moose basics will get you up to speed with many
54 of Moose's features quickly. Once you have an idea of what Moose can
55 do, you can use the API documentation to get more detail on features
56 which interest you.
57 Moose Extensions
59 The "MooseX::" namespace is the official place to find Moose
60 extensions. These extensions can be found on the CPAN. The easiest
61 way to find them is to search for them
62 (<https://metacpan.org/search?q=MooseX::>), or to examine Task::Moose
63 which aims to keep an up-to-date, easily installable list of Moose
64 extensions.
65
67 Much of the Moose documentation has been translated into other
68 languages.
69 Japanese
71 Japanese docs can be found at
72 <http://perldoc.perlassociation.org/pod/Moose-Doc-JA/index.html>.
73 The source POD files can be found in GitHub:
74 <http://github.com/jpa/Moose-Doc-JA>
75
77 Moose makes every attempt to provide as much convenience as possible
78 during class construction/definition, but still stay out of your way if
79 you want it to. Here are a few items to note when building classes with
80 Moose.
81 When you "use Moose", Moose will set the class's parent class to
83 Moose::Object, unless the class using Moose already has a parent class.
84 In addition, specifying a parent with "extends" will change the parent
85 class.
86 Moose will also manage all attributes (including inherited ones) that
88 are defined with "has". And (assuming you call "new", which is
89 inherited from Moose::Object) this includes properly initializing all
90 instance slots, setting defaults where appropriate, and performing any
91 type constraint checking or coercion.
92
94 Moose provides a number of methods to all your classes, mostly through
95 the inheritance of Moose::Object. There is however, one exception. By
96 default, Moose will install a method named "meta" in any class which
97 uses "Moose". This method returns the current class's metaclass.
98 If you'd like to rename this method, you can do so by passing the
100 "-meta_name" option when using Moose:
101 use Moose -meta_name => 'my_meta';
103 However, the Moose::Object class also provides a method named "meta"
105 which does the same thing. If your class inherits from Moose::Object
106 (which is the default), then you will still have a "meta" method.
107 However, if your class inherits from a parent which provides a "meta"
108 method of its own, your class will inherit that instead.
109 If you'd like for Moose to not install a meta method at all, you can
111 pass "undef" as the "-meta_name" option:
112 use Moose -meta_name => undef;
114 Again, you will still inherit "meta" from Moose::Object in this case.
116
118 Moose will export a number of functions into the class's namespace
119 which may then be used to set up the class. These functions all work
120 directly on the current class.
121 extends (@superclasses)
123 This function will set the superclass(es) for the current class. If the
124 parent classes are not yet loaded, then "extends" tries to load them.
125 This approach is recommended instead of "use base"/"use parent",
127 because "use base" actually "push"es onto the class's @ISA, whereas
128 "extends" will replace it. This is important to ensure that classes
129 which do not have superclasses still properly inherit from
130 Moose::Object.
131 Each superclass can be followed by a hash reference with options.
133 Currently, only -version is recognized:
134 extends 'My::Parent' => { -version => 0.01 },
136 'My::OtherParent' => { -version => 0.03 };
137 An exception will be thrown if the version requirements are not
139 satisfied.
140 with (@roles)
142 This will apply a given set of @roles to the local class.
143 Like with "extends", each specified role can be followed by a hash
145 reference with a -version option:
146 with 'My::Role' => { -version => 0.32 },
148 'My::Otherrole' => { -version => 0.23 };
149 The specified version requirements must be satisfied, otherwise an
151 exception will be thrown.
152 If your role takes options or arguments, they can be passed along in
154 the hash reference as well.
155 You should only use one "with", even if you are consuming multiple
157 roles. If you consume roles using multiple "with" statements Moose
158 cannot detect method conflicts between those roles.
159 has $name|@$names => %options
161 This will install an attribute of a given $name into the current class.
162 If the first parameter is an array reference, it will create an
163 attribute for every $name in the list. The %options will be passed to
164 the constructor for Moose::Meta::Attribute (which inherits from
165 Class::MOP::Attribute), so the full documentation for the valid options
166 can be found there. These are the most commonly used options:
167 is => 'rw'|'ro'
169 The is option accepts either rw (for read/write) or ro (for read
170 only). These will create either a read/write accessor or a read-
171 only accessor respectively, using the same name as the $name of the
172 attribute.
173 If you need more control over how your accessors are named, you can
175 use the reader, writer and accessor options inherited from
176 Class::MOP::Attribute, however if you use those, you won't need the
177 is option.
178 isa => $type_name
180 The isa option uses Moose's type constraint facilities to set up
181 runtime type checking for this attribute. Moose will perform the
182 checks during class construction, and within any accessors. The
183 $type_name argument must be a string. The string may be either a
184 class name or a type defined using Moose's type definition
185 features. (Refer to Moose::Util::TypeConstraints for information on
186 how to define a new type, and how to retrieve type meta-data).
187 coerce => (1|0)
189 This will attempt to use coercion with the supplied type constraint
190 to change the value passed into any accessors or constructors. You
191 must supply a type constraint, and that type constraint must define
192 a coercion. See Moose::Cookbook::Basics::HTTP_SubtypesAndCoercion
193 for an example.
194 does => $role_name
196 This will accept the name of a role which the value stored in this
197 attribute is expected to have consumed.
198 required => (1|0)
200 This marks the attribute as being required. This means a value must
201 be supplied during class construction, or the attribute must be
202 lazy and have either a default or a builder. Note that "required"
203 does not say anything about the attribute's value, which can be
204 "undef".
205 weak_ref => (1|0)
207 This will tell the class to store the value of this attribute as a
208 weakened reference. If an attribute is a weakened reference, it
209 cannot also be coerced. Note that when a weak ref expires, the
210 attribute's value becomes undefined, and is still considered to be
211 set for purposes of predicate, default, etc.
212 lazy => (1|0)
214 This will tell the class to not create this slot until absolutely
215 necessary. If an attribute is marked as lazy it must have a
216 default or builder supplied.
217 trigger => $code
219 The trigger option is a CODE reference which will be called after
220 the value of the attribute is set. The CODE ref is passed the
221 instance itself, the updated value, and the original value if the
222 attribute was already set.
223 You can have a trigger on a read-only attribute.
225 NOTE: Triggers will only fire when you assign to the attribute,
227 either in the constructor, or using the writer. Default and built
228 values will not cause the trigger to be fired.
229 handles => ARRAY | HASH | REGEXP | ROLE | ROLETYPE | DUCKTYPE | CODE
231 The handles option provides Moose classes with automated delegation
232 features. This is a pretty complex and powerful option. It accepts
233 many different option formats, each with its own benefits and
234 drawbacks.
235 NOTE: The class being delegated to does not need to be a Moose
237 based class, which is why this feature is especially useful when
238 wrapping non-Moose classes.
239 All handles option formats share the following traits:
241 You cannot override a locally defined method with a delegated
243 method; an exception will be thrown if you try. That is to say, if
244 you define "foo" in your class, you cannot override it with a
245 delegated "foo". This is almost never something you would want to
246 do, and if it is, you should do it by hand and not use Moose.
247 You cannot override any of the methods found in Moose::Object, or
249 the "BUILD" and "DEMOLISH" methods. These will not throw an
250 exception, but will silently move on to the next method in the
251 list. My reasoning for this is that you would almost never want to
252 do this, since it usually breaks your class. As with overriding
253 locally defined methods, if you do want to do this, you should do
254 it manually, not with Moose.
255 You do not need to have a reader (or accessor) for the attribute in
257 order to delegate to it. Moose will create a means of accessing the
258 value for you, however this will be several times less efficient
259 then if you had given the attribute a reader (or accessor) to use.
260 Below is the documentation for each option format:
262 "ARRAY"
264 This is the most common usage for handles. You basically pass a
265 list of method names to be delegated, and Moose will install a
266 delegation method for each one.
267 "HASH"
269 This is the second most common usage for handles. Instead of a
270 list of method names, you pass a HASH ref where each key is the
271 method name you want installed locally, and its value is the
272 name of the original method in the class being delegated to.
273 This can be very useful for recursive classes like trees. Here
275 is a quick example (soon to be expanded into a Moose::Cookbook
276 recipe):
277 package Tree;
279 use Moose;
280 has 'node' => (is => 'rw', isa => 'Any');
282 has 'children' => (
284 is => 'ro',
285 isa => 'ArrayRef',
286 default => sub { [] }
287 );
288 has 'parent' => (
290 is => 'rw',
291 isa => 'Tree',
292 weak_ref => 1,
293 handles => {
294 parent_node => 'node',
295 siblings => 'children',
296 }
297 );
298 In this example, the Tree package gets "parent_node" and
300 "siblings" methods, which delegate to the "node" and "children"
301 methods (respectively) of the Tree instance stored in the
302 "parent" slot.
303 You may also use an array reference to curry arguments to the
305 original method.
306 has 'thing' => (
308 ...
309 handles => { set_foo => [ set => 'foo' ] },
310 );
311 # $self->set_foo(...) calls $self->thing->set('foo', ...)
313 The first element of the array reference is the original method
315 name, and the rest is a list of curried arguments.
316 "REGEXP"
318 The regexp option works very similar to the ARRAY option,
319 except that it builds the list of methods for you. It starts by
320 collecting all possible methods of the class being delegated
321 to, then filters that list using the regexp supplied here.
322 NOTE: An isa option is required when using the regexp option
324 format. This is so that we can determine (at compile time) the
325 method list from the class. Without an isa this is just not
326 possible.
327 "ROLE" or "ROLETYPE"
329 With the role option, you specify the name of a role or a role
330 type whose "interface" then becomes the list of methods to
331 handle. The "interface" can be defined as; the methods of the
332 role and any required methods of the role. It should be noted
333 that this does not include any method modifiers or generated
334 attribute methods (which is consistent with role composition).
335 "DUCKTYPE"
337 With the duck type option, you pass a duck type object whose
338 "interface" then becomes the list of methods to handle. The
339 "interface" can be defined as the list of methods passed to
340 "duck_type" to create a duck type object. For more information
341 on "duck_type" please check Moose::Util::TypeConstraints.
342 "CODE"
344 This is the option to use when you really want to do something
345 funky. You should only use it if you really know what you are
346 doing, as it involves manual metaclass twiddling.
347 This takes a code reference, which should expect two arguments.
349 The first is the attribute meta-object this handles is attached
350 to. The second is the metaclass of the class being delegated
351 to. It expects you to return a hash (not a HASH ref) of the
352 methods you want mapped.
353 traits => [ @role_names ]
355 This tells Moose to take the list of @role_names and apply them to
356 the attribute meta-object. Custom attribute metaclass traits are
357 useful for extending the capabilities of the has keyword: they are
358 the simplest way to extend the MOP, but they are still a fairly
359 advanced topic and too much to cover here.
360 See "Metaclass and Trait Name Resolution" for details on how a
362 trait name is resolved to a role name.
363 Also see Moose::Cookbook::Meta::Labeled_AttributeTrait for a
365 metaclass trait example.
366 builder => Str
368 The value of this key is the name of the method that will be called
369 to obtain the value used to initialize the attribute. See the
370 builder option docs in Class::MOP::Attribute and/or
371 Moose::Cookbook::Basics::BinaryTree_BuilderAndLazyBuild for more
372 information.
373 default => SCALAR | CODE
375 The value of this key is the default value which will initialize
376 the attribute.
377 NOTE: If the value is a simple scalar (string or number), then it
379 can be just passed as is. However, if you wish to initialize it
380 with a HASH or ARRAY ref, then you need to wrap that inside a CODE
381 reference. See the default option docs in Class::MOP::Attribute
382 for more information.
383 clearer => Str
385 Creates a method allowing you to clear the value. See the clearer
386 option docs in Class::MOP::Attribute for more information.
387 predicate => Str
389 Creates a method to perform a basic test to see if a value has been
390 set in the attribute. See the predicate option docs in
391 Class::MOP::Attribute for more information.
392 Note that the predicate will return true even for a "weak_ref"
394 attribute whose value has expired.
395 documentation => $string
397 An arbitrary string that can be retrieved later by calling
398 "$attr->documentation".
399 has +$name => %options
401 This is variation on the normal attribute creator "has" which allows
402 you to clone and extend an attribute from a superclass or from a role.
403 Here is an example of the superclass usage:
404 package Foo;
406 use Moose;
407 has 'message' => (
409 is => 'rw',
410 isa => 'Str',
411 default => 'Hello, I am a Foo'
412 );
413 package My::Foo;
415 use Moose;
416 extends 'Foo';
418 has '+message' => (default => 'Hello I am My::Foo');
420 What is happening here is that My::Foo is cloning the "message"
422 attribute from its parent class Foo, retaining the "is => 'rw'" and
423 "isa => 'Str'" characteristics, but changing the value in "default".
424 Here is another example, but within the context of a role:
426 package Foo::Role;
428 use Moose::Role;
429 has 'message' => (
431 is => 'rw',
432 isa => 'Str',
433 default => 'Hello, I am a Foo'
434 );
435 package My::Foo;
437 use Moose;
438 with 'Foo::Role';
440 has '+message' => (default => 'Hello I am My::Foo');
442 In this case, we are basically taking the attribute which the role
444 supplied and altering it within the bounds of this feature.
445 Note that you can only extend an attribute from either a superclass or
447 a role, you cannot extend an attribute in a role that composes over an
448 attribute from another role.
449 Aside from where the attributes come from (one from superclass, the
451 other from a role), this feature works exactly the same. This feature
452 is restricted somewhat, so as to try and force at least some sanity
453 into it. Most options work the same, but there are some exceptions:
454 reader
456 writer
457 accessor
458 clearer
459 predicate
460 These options can be added, but cannot override a superclass
461 definition.
462 traits
464 You are allowed to add additional traits to the "traits"
465 definition. These traits will be composed into the attribute, but
466 preexisting traits are not overridden, or removed.
467 before $name|@names|\@names|qr/.../ => sub { ... }
469 after $name|@names|\@names|qr/.../ => sub { ... }
470 around $name|@names|\@names|qr/.../ => sub { ... }
471 These three items are syntactic sugar for the before, after, and around
472 method modifier features that Class::MOP provides. More information on
473 these may be found in Moose::Manual::MethodModifiers and the
474 Class::MOP::Class documentation.
475 override ($name, &sub)
477 An "override" method is a way of explicitly saying "I am overriding
478 this method from my superclass". You can call "super" within this
479 method, and it will work as expected. The same thing can be
480 accomplished with a normal method call and the "SUPER::" pseudo-
481 package; it is really your choice.
482 super
484 The keyword "super" is a no-op when called outside of an "override"
485 method. In the context of an "override" method, it will call the next
486 most appropriate superclass method with the same arguments as the
487 original method.
488 augment ($name, &sub)
490 An "augment" method, is a way of explicitly saying "I am augmenting
491 this method from my superclass". Once again, the details of how "inner"
492 and "augment" work is best described in the
493 Moose::Cookbook::Basics::Document_AugmentAndInner.
494 inner
496 The keyword "inner", much like "super", is a no-op outside of the
497 context of an "augment" method. You can think of "inner" as being the
498 inverse of "super"; the details of how "inner" and "augment" work is
499 best described in the
500 Moose::Cookbook::Basics::Document_AugmentAndInner.
501 blessed
503 This is the "Scalar::Util::blessed" function. It is highly recommended
504 that this is used instead of "ref" anywhere you need to test for an
505 object's class name.
506 confess
508 This is the "Carp::confess" function, and exported here for historical
509 reasons.
510
512 When you use Moose, you can specify traits which will be applied to
513 your metaclass:
514 use Moose -traits => 'My::Trait';
516 This is very similar to the attribute traits feature. When you do this,
518 your class's "meta" object will have the specified traits applied to
519 it.
520 Metaclass and Trait Name Resolution
522 By default, when given a trait name, Moose simply tries to load a class
523 of the same name. If such a class does not exist, it then looks for a
524 class matching Moose::Meta::$type::Custom::Trait::$trait_name. The
525 $type variable here will be one of Attribute or Class, depending on
526 what the trait is being applied to.
527 If a class with this long name exists, Moose checks to see if it has
529 the method "register_implementation". This method is expected to return
530 the real class name of the trait. If there is no
531 "register_implementation" method, it will fall back to using
532 Moose::Meta::$type::Custom::Trait::$trait as the trait name.
533 The lookup method for metaclasses is the same, except that it looks for
535 a class matching Moose::Meta::$type::Custom::$metaclass_name.
536 If all this is confusing, take a look at
538 Moose::Cookbook::Meta::Labeled_AttributeTrait, which demonstrates how
539 to create an attribute trait.
540
542 unimport
543 Moose offers a way to remove the keywords it exports, through the
544 "unimport" method. You simply have to say "no Moose" at the bottom of
545 your code for this to work. Here is an example:
546 package Person;
548 use Moose;
549 has 'first_name' => (is => 'rw', isa => 'Str');
551 has 'last_name' => (is => 'rw', isa => 'Str');
552 sub full_name {
554 my $self = shift;
555 $self->first_name . ' ' . $self->last_name
556 }
557 no Moose; # keywords are removed from the Person package
559
561 To learn more about extending Moose, we recommend checking out the
562 "Extending" recipes in the Moose::Cookbook, starting with
563 Moose::Cookbook::Extending::ExtensionOverview, which provides an
564 overview of all the different ways you might extend Moose.
565 Moose::Exporter and Moose::Util::MetaRole are the modules which provide
566 the majority of the extension functionality, so reading their
567 documentation should also be helpful.
568 The MooseX:: namespace
570 Generally if you're writing an extension for Moose itself you'll want
571 to put your extension in the "MooseX::" namespace. This namespace is
572 specifically for extensions that make Moose better or different in some
573 fundamental way. It is traditionally not for a package that just
574 happens to use Moose. This namespace follows from the examples of the
575 "LWPx::" and "DBIx::" namespaces that perform the same function for
576 "LWP" and "DBI" respectively.
577
579 Metaclass compatibility is a thorny subject. You should start by
580 reading the "About Metaclass compatibility" section in the Class::MOP
581 docs.
582 Moose will attempt to resolve a few cases of metaclass incompatibility
584 when you set the superclasses for a class, in addition to the cases
585 that Class::MOP handles.
586 Moose tries to determine if the metaclasses only "differ by roles".
588 This means that the parent and child's metaclass share a common
589 ancestor in their respective hierarchies, and that the subclasses under
590 the common ancestor are only different because of role applications.
591 This case is actually fairly common when you mix and match various
592 "MooseX::*" modules, many of which apply roles to the metaclass.
593 If the parent and child do differ by roles, Moose replaces the
595 metaclass in the child with a newly created metaclass. This metaclass
596 is a subclass of the parent's metaclass which does all of the roles
597 that the child's metaclass did before being replaced. Effectively, this
598 means the new metaclass does all of the roles done by both the parent's
599 and child's original metaclasses.
600 Ultimately, this is all transparent to you except in the case of an
602 unresolvable conflict.
603
605 It should be noted that "super" and "inner" cannot be used in the same
606 method. However, they may be combined within the same class hierarchy;
607 see t/basics/override_augment_inner_super.t for an example.
608 The reason for this is that "super" is only valid within a method with
610 the "override" modifier, and "inner" will never be valid within an
611 "override" method. In fact, "augment" will skip over any "override"
612 methods when searching for its appropriate "inner".
613 This might seem like a restriction, but I am of the opinion that
615 keeping these two features separate (yet interoperable) actually makes
616 them easy to use, since their behavior is then easier to predict. Time
617 will tell whether I am right or not (UPDATE: so far so good).
618
620 We offer both a mailing list and a very active IRC channel.
621 The mailing list is <mailto:moose@perl.org>. You must be subscribed to
623 send a message. To subscribe, send an empty message to
624 <mailto:moose-subscribe@perl.org>
625 You can also visit us at "#moose" on <irc://irc.perl.org/#moose> This
627 channel is quite active, and questions at all levels (on Moose-related
628 topics ;) are welcome.
629
631 Moose doesn't stand for one thing in particular, however, if you want,
632 here are a few of our favorites. Feel free to contribute more!
633 • Make Other Object Systems Envious
635 • Makes Object Orientation So Easy
637 • Makes Object Orientation Spiffy- Er (sorry ingy)
639 • Most Other Object Systems Emasculate
641 • Moose Often Ovulate Sorta Early
643 • Moose Offers Often Super Extensions
645 • Meta Object Obligates Salivary Excitation
647 • Meta Object Orientation Syntax Extensions
649 • Moo, Only Overengineered, Slow, and Execrable (blame rjbs!)
651 • Massive Object-Oriented Stacktrace Emitter
653
655 I blame Sam Vilain for introducing me to the insanity that is meta-
656 models.
657 I blame Audrey Tang for then encouraging my meta-model habit in #perl6.
658 Without Yuval "nothingmuch" Kogman this module would not be possible,
659 and it certainly wouldn't have this name ;P
660 The basis of the TypeContraints module was Rob Kinyon's idea
661 originally, I just ran with it.
662 Thanks to mst & chansen and the whole #moose posse for all the early
663 ideas/feature-requests/encouragement/bug-finding.
664 Thanks to David "Theory" Wheeler for meta-discussions and spelling
665 fixes.
666
668 <http://moose.perl.org/>
669 This is the official web home of Moose. It contains links to our
670 public git repository, as well as links to a number of talks and
671 articles on Moose and Moose related technologies.
672 the Moose manual
674 This is an introduction to Moose which covers most of the basics.
675 Modern Perl, by chromatic
677 This is an introduction to modern Perl programming, which includes
678 a section on Moose. It is available in print and as a free download
679 from <http://onyxneon.com/books/modern_perl/>.
680 The Moose is flying, a tutorial by Randal Schwartz
682 Part 1 - <http://www.stonehenge.com/merlyn/LinuxMag/col94.html>
683 Part 2 - <http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
685 Several Moose extension modules in the "MooseX::" namespace.
687 See <https://metacpan.org/search?q=MooseX::> for extensions.
688 Books
690 The Art of the MetaObject Protocol
691 I mention this in the Class::MOP docs too, as this book was
692 critical in the development of both modules and is highly
693 recommended.
694 Papers
696 <http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf>
697 This paper (suggested by lbr on #moose) was what lead to the
698 implementation of the "super"/"override" and "inner"/"augment"
699 features. If you really want to understand them, I suggest you read
700 this.
701
703 All complex software has bugs lurking in it, and this module is no
704 exception.
705 Please report any bugs to "bug-moose@rt.cpan.org", or through the web
707 interface at <http://rt.cpan.org>. You can also submit a "TODO" test as
708 a pull request at <https://github.com/moose/Moose>.
709 You can also discuss feature requests or possible bugs on the Moose
711 mailing list (moose@perl.org) or on IRC at <irc://irc.perl.org/#moose>.
712
714 We are very strict about what features we add to the Moose core,
715 especially the user-visible features. Instead we have made sure that
716 the underlying meta-system of Moose is as extensible as possible so
717 that you can add your own features easily.
718 That said, occasionally there is a feature needed in the meta-system to
720 support your planned extension, in which case you should either email
721 the mailing list (moose@perl.org) or join us on IRC at
722 <irc://irc.perl.org/#moose> to discuss. The Moose::Manual::Contributing
723 has more detail about how and when you can contribute.
724
726 There are only a few people with the rights to release a new version of
727 Moose. The Moose Cabal are the people to go to with questions regarding
728 the wider purview of Moose. They help maintain not just the code but
729 the community as well. See the list below under "AUTHORS".
730
732 Moose is a community project, and as such, involves the work of many,
733 many members of the community beyond just the members in the cabal. In
734 particular:
735 Dave (autarch) Rolsky wrote most of the documentation in Moose::Manual.
737 John (jgoulah) Goulah wrote Moose::Cookbook::Snack::Keywords.
739 Jess (castaway) Robinson wrote Moose::Cookbook::Snack::Types.
741 Aran (bluefeet) Clary Deltac wrote
743 Moose::Cookbook::Basics::Genome_OverloadingSubtypesAndCoercion.
744 Anders (Debolaz) Nor Berle contributed Test::Moose and Moose::Util.
746 Also, the code in Moose::Meta::Attribute::Native is based on code from
748 the MooseX::AttributeHelpers distribution, which had contributions
749 from:
750 Chris (perigrin) Prather
752 Cory (gphat) Watson
754 Evan Carroll
756 Florian (rafl) Ragwitz
758 Jason May
760 Jay Hannah
762 Jesse (doy) Luehrs
764 Paul (frodwith) Driver
766 Robert (rlb3) Boone
768 Robert Buels
770 Robert (phaylon) Sedlacek
772 Shawn (Sartak) Moore
774 Stevan Little
776 Tom (dec) Lanyon
778 Yuval Kogman
780 Finally, these people also contributed various tests, bug fixes,
782 documentation, and features to the Moose codebase:
783 Aankhen
785 Adam (Alias) Kennedy
787 Christian (chansen) Hansen
789 Cory (gphat) Watson
791 Dylan Hardison (doc fixes)
793 Eric (ewilhelm) Wilhelm
795 Evan Carroll
797 Guillermo (groditi) Roditi
799 Jason May
801 Jay Hannah
803 Jonathan (jrockway) Rockway
805 Matt (mst) Trout
807 Nathan (kolibrie) Gray
809 Paul (frodwith) Driver
811 Piotr (dexter) Roszatycki
813 Robert Buels
815 Robert (phaylon) Sedlacek
817 Robert (rlb3) Boone
819 Sam (mugwump) Vilain
821 Scott (konobi) McWhirter
823 Shlomi (rindolf) Fish
825 Tom (dec) Lanyon
827 Wallace (wreis) Reis
829 ... and many other #moose folks
831
833 • Stevan Little <stevan@cpan.org>
834 • Dave Rolsky <autarch@urth.org>
836 • Jesse Luehrs <doy@cpan.org>
838 • Shawn M Moore <sartak@cpan.org>
840 • יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
842 • Karen Etheridge <ether@cpan.org>
844 • Florian Ragwitz <rafl@debian.org>
846 • Hans Dieter Pearcey <hdp@cpan.org>
848 • Chris Prather <chris@prather.org>
850 • Matt S Trout <mstrout@cpan.org>
852
854 This software is copyright (c) 2006 by Infinity Interactive, Inc.
855 This is free software; you can redistribute it and/or modify it under
857 the same terms as the Perl 5 programming language system itself.
858perl v5.32.1 2021-01-27 Moose(3)