1Moose(3)              User Contributed Perl Documentation             Moose(3)
2
3
4

NAME

6       Moose - A postmodern object system for Perl 5
7

VERSION

9       version 2.2203
10

SYNOPSIS

12         package Point;
13         use Moose; # automatically turns on strict and warnings
14
15         has 'x' => (is => 'rw', isa => 'Int');
16         has 'y' => (is => 'rw', isa => 'Int');
17
18         sub clear {
19             my $self = shift;
20             $self->x(0);
21             $self->y(0);
22         }
23
24         package Point3D;
25         use Moose;
26
27         extends 'Point';
28
29         has 'z' => (is => 'rw', isa => 'Int');
30
31         after 'clear' => sub {
32             my $self = shift;
33             $self->z(0);
34         };
35

DESCRIPTION

37       Moose is an extension of the Perl 5 object system.
38
39       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
43       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
48   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
53       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
58   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

TRANSLATIONS

67       Much of the Moose documentation has been translated into other
68       languages.
69
70       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

BUILDING CLASSES WITH MOOSE

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
82       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
87       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

PROVIDED METHODS

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
99       If you'd like to rename this method, you can do so by passing the
100       "-meta_name" option when using Moose:
101
102           use Moose -meta_name => 'my_meta';
103
104       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
110       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
113           use Moose -meta_name => undef;
114
115       Again, you will still inherit "meta" from Moose::Object in this case.
116

EXPORTED FUNCTIONS

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
122   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
126       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
132       Each superclass can be followed by a hash reference with options.
133       Currently, only -version is recognized:
134
135           extends 'My::Parent'      => { -version => 0.01 },
136                   'My::OtherParent' => { -version => 0.03 };
137
138       An exception will be thrown if the version requirements are not
139       satisfied.
140
141   with (@roles)
142       This will apply a given set of @roles to the local class.
143
144       Like with "extends", each specified role can be followed by a hash
145       reference with a -version option:
146
147           with 'My::Role'      => { -version => 0.32 },
148                'My::Otherrole' => { -version => 0.23 };
149
150       The specified version requirements must be satisfied, otherwise an
151       exception will be thrown.
152
153       If your role takes options or arguments, they can be passed along in
154       the hash reference as well.
155
156       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
160   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
168       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
174           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
179       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
188       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
195       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
199       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
206       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
213       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
218       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
224           You can have a trigger on a read-only attribute.
225
226           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
230       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
236           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
240           All handles option formats share the following traits:
241
242           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
248           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
256           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
261           Below is the documentation for each option format:
262
263           "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
268           "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
274               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
278                 package Tree;
279                 use Moose;
280
281                 has 'node' => (is => 'rw', isa => 'Any');
282
283                 has 'children' => (
284                     is      => 'ro',
285                     isa     => 'ArrayRef',
286                     default => sub { [] }
287                 );
288
289                 has 'parent' => (
290                     is          => 'rw',
291                     isa         => 'Tree',
292                     weak_ref    => 1,
293                     handles     => {
294                         parent_node => 'node',
295                         siblings    => 'children',
296                     }
297                 );
298
299               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
304               You may also use an array reference to curry arguments to the
305               original method.
306
307                 has 'thing' => (
308                     ...
309                     handles => { set_foo => [ set => 'foo' ] },
310                 );
311
312                 # $self->set_foo(...) calls $self->thing->set('foo', ...)
313
314               The first element of the array reference is the original method
315               name, and the rest is a list of curried arguments.
316
317           "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
323               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
328           "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
336           "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
343           "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
348               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
354       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
361           See "Metaclass and Trait Name Resolution" for details on how a
362           trait name is resolved to a role name.
363
364           Also see Moose::Cookbook::Meta::Labeled_AttributeTrait for a
365           metaclass trait example.
366
367       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
374       default => SCALAR | CODE
375           The value of this key is the default value which will initialize
376           the attribute.
377
378           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
384       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
388       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
393           Note that the predicate will return true even for a "weak_ref"
394           attribute whose value has expired.
395
396       documentation => $string
397           An arbitrary string that can be retrieved later by calling
398           "$attr->documentation".
399
400   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
405         package Foo;
406         use Moose;
407
408         has 'message' => (
409             is      => 'rw',
410             isa     => 'Str',
411             default => 'Hello, I am a Foo'
412         );
413
414         package My::Foo;
415         use Moose;
416
417         extends 'Foo';
418
419         has '+message' => (default => 'Hello I am My::Foo');
420
421       What is happening here is that My::Foo is cloning the "message"
422       attribute from its parent class Foo, retaining the "is => 'rw'" and isa
423       => 'Str' characteristics, but changing the value in "default".
424
425       Here is another example, but within the context of a role:
426
427         package Foo::Role;
428         use Moose::Role;
429
430         has 'message' => (
431             is      => 'rw',
432             isa     => 'Str',
433             default => 'Hello, I am a Foo'
434         );
435
436         package My::Foo;
437         use Moose;
438
439         with 'Foo::Role';
440
441         has '+message' => (default => 'Hello I am My::Foo');
442
443       In this case, we are basically taking the attribute which the role
444       supplied and altering it within the bounds of this feature.
445
446       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
450       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
455       reader
456       writer
457       accessor
458       clearer
459       predicate
460           These options can be added, but cannot override a superclass
461           definition.
462
463       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
468   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
476   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
483   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
489   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
495   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
502   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
507   confess
508       This is the "Carp::confess" function, and exported here for historical
509       reasons.
510

METACLASS

512       When you use Moose, you can specify traits which will be applied to
513       your metaclass:
514
515           use Moose -traits => 'My::Trait';
516
517       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
521   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
528       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
534       The lookup method for metaclasses is the same, except that it looks for
535       a class matching Moose::Meta::$type::Custom::$metaclass_name.
536
537       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

UNIMPORTING FUNCTIONS

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
547           package Person;
548           use Moose;
549
550           has 'first_name' => (is => 'rw', isa => 'Str');
551           has 'last_name'  => (is => 'rw', isa => 'Str');
552
553           sub full_name {
554               my $self = shift;
555               $self->first_name . ' ' . $self->last_name
556           }
557
558           no Moose; # keywords are removed from the Person package
559

EXTENDING AND EMBEDDING MOOSE

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
569   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

METACLASS COMPATIBILITY AND MOOSE

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
583       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
587       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
594       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
601       Ultimately, this is all transparent to you except in the case of an
602       unresolvable conflict.
603

CAVEATS

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
609       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
614       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

GETTING HELP

620       We offer both a mailing list and a very active IRC channel.
621
622       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
626       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

WHAT DOES MOOSE STAND FOR?

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
634       •   Make Other Object Systems Envious
635
636       •   Makes Object Orientation So Easy
637
638       •   Makes Object Orientation Spiffy- Er (sorry ingy)
639
640       •   Most Other Object Systems Emasculate
641
642       •   Moose Often Ovulate Sorta Early
643
644       •   Moose Offers Often Super Extensions
645
646       •   Meta Object Obligates Salivary Excitation
647
648       •   Meta Object Orientation Syntax Extensions
649
650       •   Moo, Only Overengineered, Slow, and Execrable (blame rjbs!)
651
652       •   Massive Object-Oriented Stacktrace Emitter
653

ACKNOWLEDGEMENTS

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

SEE ALSO

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
673       the Moose manual
674           This is an introduction to Moose which covers most of the basics.
675
676       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
681       The Moose is flying, a tutorial by Randal Schwartz
682           Part 1 - <http://www.stonehenge.com/merlyn/LinuxMag/col94.html>
683
684           Part 2 - <http://www.stonehenge.com/merlyn/LinuxMag/col95.html>
685
686       Several Moose extension modules in the "MooseX::" namespace.
687           See <https://metacpan.org/search?q=MooseX::> for extensions.
688
689   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
695   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

BUGS

703       All complex software has bugs lurking in it, and this module is no
704       exception.
705
706       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
710       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

FEATURE REQUESTS

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
719       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

CABAL

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

CONTRIBUTORS

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
736       Dave (autarch) Rolsky wrote most of the documentation in Moose::Manual.
737
738       John (jgoulah) Goulah wrote Moose::Cookbook::Snack::Keywords.
739
740       Jess (castaway) Robinson wrote Moose::Cookbook::Snack::Types.
741
742       Aran (bluefeet) Clary Deltac wrote
743       Moose::Cookbook::Basics::Genome_OverloadingSubtypesAndCoercion.
744
745       Anders (Debolaz) Nor Berle contributed Test::Moose and Moose::Util.
746
747       Also, the code in Moose::Meta::Attribute::Native is based on code from
748       the MooseX::AttributeHelpers distribution, which had contributions
749       from:
750
751       Chris (perigrin) Prather
752
753       Cory (gphat) Watson
754
755       Evan Carroll
756
757       Florian (rafl) Ragwitz
758
759       Jason May
760
761       Jay Hannah
762
763       Jesse (doy) Luehrs
764
765       Paul (frodwith) Driver
766
767       Robert (rlb3) Boone
768
769       Robert Buels
770
771       Robert (phaylon) Sedlacek
772
773       Shawn (Sartak) Moore
774
775       Stevan Little
776
777       Tom (dec) Lanyon
778
779       Yuval Kogman
780
781       Finally, these people also contributed various tests, bug fixes,
782       documentation, and features to the Moose codebase:
783
784       Aankhen
785
786       Adam (Alias) Kennedy
787
788       Christian (chansen) Hansen
789
790       Cory (gphat) Watson
791
792       Dylan Hardison (doc fixes)
793
794       Eric (ewilhelm) Wilhelm
795
796       Evan Carroll
797
798       Guillermo (groditi) Roditi
799
800       Jason May
801
802       Jay Hannah
803
804       Jonathan (jrockway) Rockway
805
806       Matt (mst) Trout
807
808       Nathan (kolibrie) Gray
809
810       Paul (frodwith) Driver
811
812       Piotr (dexter) Roszatycki
813
814       Robert Buels
815
816       Robert (phaylon) Sedlacek
817
818       Robert (rlb3) Boone
819
820       Sam (mugwump) Vilain
821
822       Scott (konobi) McWhirter
823
824       Shlomi (rindolf) Fish
825
826       Tom (dec) Lanyon
827
828       Wallace (wreis) Reis
829
830       ... and many other #moose folks
831

AUTHORS

833       •   Stevan Little <stevan@cpan.org>
834
835       •   Dave Rolsky <autarch@urth.org>
836
837       •   Jesse Luehrs <doy@cpan.org>
838
839       •   Shawn M Moore <sartak@cpan.org>
840
841       •   יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
842
843       •   Karen Etheridge <ether@cpan.org>
844
845       •   Florian Ragwitz <rafl@debian.org>
846
847       •   Hans Dieter Pearcey <hdp@cpan.org>
848
849       •   Chris Prather <chris@prather.org>
850
851       •   Matt S Trout <mstrout@cpan.org>
852
854       This software is copyright (c) 2006 by Infinity Interactive, Inc.
855
856       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.
858
859
860
861perl v5.36.0                      2023-02-06                          Moose(3)
Impressum