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

NAME

6       Moo - Minimalist Object Orientation (with Moose compatibility)
7

SYNOPSIS

9         package Cat::Food;
10
11         use Moo;
12         use strictures 2;
13         use namespace::clean;
14
15         sub feed_lion {
16           my $self = shift;
17           my $amount = shift || 1;
18
19           $self->pounds( $self->pounds - $amount );
20         }
21
22         has taste => (
23           is => 'ro',
24         );
25
26         has brand => (
27           is  => 'ro',
28           isa => sub {
29             die "Only SWEET-TREATZ supported!" unless $_[0] eq 'SWEET-TREATZ'
30           },
31         );
32
33         has pounds => (
34           is  => 'rw',
35           isa => sub { die "$_[0] is too much cat food!" unless $_[0] < 15 },
36         );
37
38         1;
39
40       And elsewhere:
41
42         my $full = Cat::Food->new(
43             taste  => 'DELICIOUS.',
44             brand  => 'SWEET-TREATZ',
45             pounds => 10,
46         );
47
48         $full->feed_lion;
49
50         say $full->pounds;
51

DESCRIPTION

53       "Moo" is an extremely light-weight Object Orientation system. It allows
54       one to concisely define objects and roles with a convenient syntax that
55       avoids the details of Perl's object system.  "Moo" contains a subset of
56       Moose and is optimised for rapid startup.
57
58       "Moo" avoids depending on any XS modules to allow for simple
59       deployments.  The name "Moo" is based on the idea that it provides
60       almost -- but not quite -- two thirds of Moose.
61
62       Unlike Mouse this module does not aim at full compatibility with
63       Moose's surface syntax, preferring instead to provide full
64       interoperability via the metaclass inflation capabilities described in
65       "MOO AND MOOSE".
66
67       For a full list of the minor differences between Moose and Moo's
68       surface syntax, see "INCOMPATIBILITIES WITH MOOSE".
69

WHY MOO EXISTS

71       If you want a full object system with a rich Metaprotocol, Moose is
72       already wonderful.
73
74       But if you don't want to use Moose, you may not want "less
75       metaprotocol" like Mouse offers, but you probably want "no
76       metaprotocol", which is what Moo provides. "Moo" is ideal for some
77       situations where deployment or startup time precludes using Moose and
78       Mouse:
79
80       a command line or CGI script where fast startup is essential
81       code designed to be deployed as a single file via App::FatPacker
82       a CPAN module that may be used by others in the above situations
83
84       "Moo" maintains transparent compatibility with Moose so if you install
85       and load Moose you can use Moo classes and roles in Moose code without
86       modification.
87
88       Moo -- Minimal Object Orientation -- aims to make it smooth to upgrade
89       to Moose when you need more than the minimal features offered by Moo.
90

MOO AND MOOSE

92       If Moo detects Moose being loaded, it will automatically register
93       metaclasses for your Moo and Moo::Role packages, so you should be able
94       to use them in Moose code without modification.
95
96       Moo will also create Moose type constraints for Moo classes and roles,
97       so that in Moose classes "isa => 'MyMooClass'" and "isa => 'MyMooRole'"
98       work the same as for Moose classes and roles.
99
100       Extending a Moose class or consuming a Moose::Role will also work.
101
102       Extending a Mouse class or consuming a Mouse::Role will also work. But
103       note that we don't provide Mouse metaclasses or metaroles so the other
104       way around doesn't work. This feature exists for Any::Moose users
105       porting to Moo; enabling Mouse users to use Moo classes is not a
106       priority for us.
107
108       This means that there is no need for anything like Any::Moose for Moo
109       code - Moo and Moose code should simply interoperate without problem.
110       To handle Mouse code, you'll likely need an empty Moo role or class
111       consuming or extending the Mouse stuff since it doesn't register true
112       Moose metaclasses like Moo does.
113
114       If you need to disable the metaclass creation, add:
115
116         no Moo::sification;
117
118       to your code before Moose is loaded, but bear in mind that this switch
119       is global and turns the mechanism off entirely so don't put this in
120       library code.
121

MOO AND CLASS::XSACCESSOR

123       If a new enough version of Class::XSAccessor is available, it will be
124       used to generate simple accessors, readers, and writers for better
125       performance.  Simple accessors are those without lazy defaults, type
126       checks/coercions, or triggers.  Simple readers are those without lazy
127       defaults. Readers and writers generated by Class::XSAccessor will
128       behave slightly differently: they will reject attempts to call them
129       with the incorrect number of parameters.
130

MOO VERSUS ANY::MOOSE

132       Any::Moose will load Mouse normally, and Moose in a program using Moose
133       - which theoretically allows you to get the startup time of Mouse
134       without disadvantaging Moose users.
135
136       Sadly, this doesn't entirely work, since the selection is load order
137       dependent - Moo's metaclass inflation system explained above in "MOO
138       AND MOOSE" is significantly more reliable.
139
140       So if you want to write a CPAN module that loads fast or has only pure
141       perl dependencies but is also fully usable by Moose users, you should
142       be using Moo.
143
144       For a full explanation, see the article
145       <http://shadow.cat/blog/matt-s-trout/moo-versus-any-moose> which
146       explains the differing strategies in more detail and provides a direct
147       example of where Moo succeeds and Any::Moose fails.
148

PUBLIC METHODS

150       Moo provides several methods to any class using it.
151
152   new
153         Foo::Bar->new( attr1 => 3 );
154
155       or
156
157         Foo::Bar->new({ attr1 => 3 });
158
159       The constructor for the class.  By default it will accept attributes
160       either as a hashref, or a list of key value pairs.  This can be
161       customized with the "BUILDARGS" method.
162
163   does
164         if ($foo->does('Some::Role1')) {
165           ...
166         }
167
168       Returns true if the object composes in the passed role.
169
170   DOES
171         if ($foo->DOES('Some::Role1') || $foo->DOES('Some::Class1')) {
172           ...
173         }
174
175       Similar to "does", but will also return true for both composed roles
176       and superclasses.
177
178   meta
179         my $meta = Foo::Bar->meta;
180         my @methods = $meta->get_method_list;
181
182       Returns an object that will behave as if it is a Moose metaclass object
183       for the class. If you call anything other than "make_immutable" on it,
184       the object will be transparently upgraded to a genuine
185       Moose::Meta::Class instance, loading Moose in the process if required.
186       "make_immutable" itself is a no-op, since we generate metaclasses that
187       are already immutable, and users converting from Moose had an
188       unfortunate tendency to accidentally load Moose by calling it.
189

LIFECYCLE METHODS

191       There are several methods that you can define in your class to control
192       construction and destruction of objects.  They should be used rather
193       than trying to modify "new" or "DESTROY" yourself.
194
195   BUILDARGS
196         around BUILDARGS => sub {
197           my ( $orig, $class, @args ) = @_;
198
199           return { attr1 => $args[0] }
200             if @args == 1 && !ref $args[0];
201
202           return $class->$orig(@args);
203         };
204
205         Foo::Bar->new( 3 );
206
207       This class method is used to transform the arguments to "new" into a
208       hash reference of attribute values.
209
210       The default implementation accepts a hash or hash reference of named
211       parameters.  If it receives a single argument that isn't a hash
212       reference it will throw an error.
213
214       You can override this method in your class to handle other types of
215       options passed to the constructor.
216
217       This method should always return a hash reference of named options.
218
219   FOREIGNBUILDARGS
220         sub FOREIGNBUILDARGS {
221           my ( $class, $options ) = @_;
222           return $options->{foo};
223         }
224
225       If you are inheriting from a non-Moo class, the arguments passed to the
226       parent class constructor can be manipulated by defining a
227       "FOREIGNBUILDARGS" method.  It will receive the same arguments as
228       "BUILDARGS", and should return a list of arguments to pass to the
229       parent class constructor.
230
231   BUILD
232         sub BUILD {
233           my ($self, $args) = @_;
234           die "foo and bar cannot be used at the same time"
235             if exists $args->{foo} && exists $args->{bar};
236         }
237
238       On object creation, any "BUILD" methods in the class's inheritance
239       hierarchy will be called on the object and given the results of
240       "BUILDARGS".  They each will be called in order from the parent classes
241       down to the child, and thus should not themselves call the parent's
242       method.  Typically this is used for object validation or possibly
243       logging.
244
245   DEMOLISH
246         sub DEMOLISH {
247           my ($self, $in_global_destruction) = @_;
248           ...
249         }
250
251       When an object is destroyed, any "DEMOLISH" methods in the inheritance
252       hierarchy will be called on the object.  They are given boolean to
253       inform them if global destruction is in progress, and are called from
254       the child class upwards to the parent.  This is similar to "BUILD"
255       methods but in the opposite order.
256
257       Note that this is implemented by a "DESTROY" method, which is only
258       created on on the first construction of an object of your class.  This
259       saves on overhead for classes that are never instantiated or those
260       without "DEMOLISH" methods.  If you try to define your own "DESTROY",
261       this will cause undefined results.
262

IMPORTED SUBROUTINES

264   extends
265         extends 'Parent::Class';
266
267       Declares a base class. Multiple superclasses can be passed for multiple
268       inheritance but please consider using roles instead.  The class will be
269       loaded but no errors will be triggered if the class can't be found and
270       there are already subs in the class.
271
272       Calling extends more than once will REPLACE your superclasses, not add
273       to them like 'use base' would.
274
275   with
276         with 'Some::Role1';
277
278       or
279
280         with 'Some::Role1', 'Some::Role2';
281
282       Composes one or more Moo::Role (or Role::Tiny) roles into the current
283       class.  An error will be raised if these roles cannot be composed
284       because they have conflicting method definitions.  The roles will be
285       loaded using the same mechanism as "extends" uses.
286
287   has
288         has attr => (
289           is => 'ro',
290         );
291
292       Declares an attribute for the class.
293
294         package Foo;
295         use Moo;
296         has 'attr' => (
297           is => 'ro'
298         );
299
300         package Bar;
301         use Moo;
302         extends 'Foo';
303         has '+attr' => (
304           default => sub { "blah" },
305         );
306
307       Using the "+" notation, it's possible to override an attribute.
308
309         has [qw(attr1 attr2 attr3)] => (
310           is => 'ro',
311         );
312
313       Using an arrayref with multiple attribute names, it's possible to
314       declare multiple attributes with the same options.
315
316       The options for "has" are as follows:
317
318       "is"
319         required, may be "ro", "lazy", "rwp" or "rw".
320
321         "ro" stands for "read-only" and generates an accessor that dies if
322         you attempt to write to it - i.e.  a getter only - by defaulting
323         "reader" to the name of the attribute.
324
325         "lazy" generates a reader like "ro", but also sets "lazy" to 1 and
326         "builder" to "_build_${attribute_name}" to allow on-demand generated
327         attributes.  This feature was my attempt to fix my incompetence when
328         originally designing "lazy_build", and is also implemented by
329         MooseX::AttributeShortcuts. There is, however, nothing to stop you
330         using "lazy" and "builder" yourself with "rwp" or "rw" - it's just
331         that this isn't generally a good idea so we don't provide a shortcut
332         for it.
333
334         "rwp" stands for "read-write protected" and generates a reader like
335         "ro", but also sets "writer" to "_set_${attribute_name}" for
336         attributes that are designed to be written from inside of the class,
337         but read-only from outside.  This feature comes from
338         MooseX::AttributeShortcuts.
339
340         "rw" stands for "read-write" and generates a normal getter/setter by
341         defaulting the "accessor" to the name of the attribute specified.
342
343       "isa"
344         Takes a coderef which is used to validate the attribute.  Unlike
345         Moose, Moo does not include a basic type system, so instead of doing
346         "isa => 'Num'", one should do
347
348           use Scalar::Util qw(looks_like_number);
349           ...
350           isa => sub {
351             die "$_[0] is not a number!" unless looks_like_number $_[0]
352           },
353
354         Note that the return value for "isa" is discarded. Only if the sub
355         dies does type validation fail.
356
357         Sub::Quote aware
358
359         Since Moo does not run the "isa" check before "coerce" if a coercion
360         subroutine has been supplied, "isa" checks are not structural to your
361         code and can, if desired, be omitted on non-debug builds (although if
362         this results in an uncaught bug causing your program to break, the
363         Moo authors guarantee nothing except that you get to keep both
364         halves).
365
366         If you want Moose compatible or MooseX::Types style named types, look
367         at Type::Tiny.
368
369         To cause your "isa" entries to be automatically mapped to named
370         Moose::Meta::TypeConstraint objects (rather than the default
371         behaviour of creating an anonymous type), set:
372
373           $Moo::HandleMoose::TYPE_MAP{$isa_coderef} = sub {
374             require MooseX::Types::Something;
375             return MooseX::Types::Something::TypeName();
376           };
377
378         Note that this example is purely illustrative; anything that returns
379         a Moose::Meta::TypeConstraint object or something similar enough to
380         it to make Moose happy is fine.
381
382       "coerce"
383         Takes a coderef which is meant to coerce the attribute.  The basic
384         idea is to do something like the following:
385
386          coerce => sub {
387            $_[0] % 2 ? $_[0] : $_[0] + 1
388          },
389
390         Note that Moo will always execute your coercion: this is to permit
391         "isa" entries to be used purely for bug trapping, whereas coercions
392         are always structural to your code. We do, however, apply any
393         supplied "isa" check after the coercion has run to ensure that it
394         returned a valid value.
395
396         Sub::Quote aware
397
398         If the "isa" option is a blessed object providing a "coerce" or
399         "coercion" method, then the "coerce" option may be set to just 1.
400
401       "handles"
402         Takes a string
403
404           handles => 'RobotRole'
405
406         Where "RobotRole" is a role that defines an interface which becomes
407         the list of methods to handle.
408
409         Takes a list of methods
410
411           handles => [ qw( one two ) ]
412
413         Takes a hashref
414
415           handles => {
416             un => 'one',
417           }
418
419       "trigger"
420         Takes a coderef which will get called any time the attribute is set.
421         This includes the constructor, but not default or built values. The
422         coderef will be invoked against the object with the new value as an
423         argument.
424
425         If you set this to just 1, it generates a trigger which calls the
426         "_trigger_${attr_name}" method on $self. This feature comes from
427         MooseX::AttributeShortcuts.
428
429         Note that Moose also passes the old value, if any; this feature is
430         not yet supported.
431
432         Sub::Quote aware
433
434       "default"
435         Takes a coderef which will get called with $self as its only argument
436         to populate an attribute if no value for that attribute was supplied
437         to the constructor. Alternatively, if the attribute is lazy,
438         "default" executes when the attribute is first retrieved if no value
439         has yet been provided.
440
441         If a simple scalar is provided, it will be inlined as a string. Any
442         non-code reference (hash, array) will result in an error - for that
443         case instead use a code reference that returns the desired value.
444
445         Note that if your default is fired during new() there is no guarantee
446         that other attributes have been populated yet so you should not rely
447         on their existence.
448
449         Sub::Quote aware
450
451       "predicate"
452         Takes a method name which will return true if an attribute has a
453         value.
454
455         If you set this to just 1, the predicate is automatically named
456         "has_${attr_name}" if your attribute's name does not start with an
457         underscore, or "_has_${attr_name_without_the_underscore}" if it does.
458         This feature comes from MooseX::AttributeShortcuts.
459
460       "builder"
461         Takes a method name which will be called to create the attribute -
462         functions exactly like default except that instead of calling
463
464           $default->($self);
465
466         Moo will call
467
468           $self->$builder;
469
470         The following features come from MooseX::AttributeShortcuts:
471
472         If you set this to just 1, the builder is automatically named
473         "_build_${attr_name}".
474
475         If you set this to a coderef or code-convertible object, that
476         variable will be installed under "$class::_build_${attr_name}" and
477         the builder set to the same name.
478
479       "clearer"
480         Takes a method name which will clear the attribute.
481
482         If you set this to just 1, the clearer is automatically named
483         "clear_${attr_name}" if your attribute's name does not start with an
484         underscore, or "_clear_${attr_name_without_the_underscore}" if it
485         does.  This feature comes from MooseX::AttributeShortcuts.
486
487         NOTE: If the attribute is "lazy", it will be regenerated from
488         "default" or "builder" the next time it is accessed. If it is not
489         lazy, it will be "undef".
490
491       "lazy"
492         Boolean.  Set this if you want values for the attribute to be grabbed
493         lazily.  This is usually a good idea if you have a "builder" which
494         requires another attribute to be set.
495
496       "required"
497         Boolean.  Set this if the attribute must be passed on object
498         instantiation.
499
500       "reader"
501         The name of the method that returns the value of the attribute.  If
502         you like Java style methods, you might set this to "get_foo"
503
504       "writer"
505         The value of this attribute will be the name of the method to set the
506         value of the attribute.  If you like Java style methods, you might
507         set this to "set_foo".
508
509       "weak_ref"
510         Boolean.  Set this if you want the reference that the attribute
511         contains to be weakened. Use this when circular references, which
512         cause memory leaks, are possible.
513
514       "init_arg"
515         Takes the name of the key to look for at instantiation time of the
516         object.  A common use of this is to make an underscored attribute
517         have a non-underscored initialization name. "undef" means that
518         passing the value in on instantiation is ignored.
519
520       "moosify"
521         Takes either a coderef or array of coderefs which is meant to
522         transform the given attributes specifications if necessary when
523         upgrading to a Moose role or class. You shouldn't need this by
524         default, but is provided as a means of possible extensibility.
525
526   before
527         before foo => sub { ... };
528
529       See "before method(s) => sub { ... };" in Class::Method::Modifiers for
530       full documentation.
531
532   around
533         around foo => sub { ... };
534
535       See "around method(s) => sub { ... };" in Class::Method::Modifiers for
536       full documentation.
537
538   after
539         after foo => sub { ... };
540
541       See "after method(s) => sub { ... };" in Class::Method::Modifiers for
542       full documentation.
543

SUB QUOTE AWARE

545       "quote_sub" in Sub::Quote allows us to create coderefs that are
546       "inlineable," giving us a handy, XS-free speed boost.  Any option that
547       is Sub::Quote aware can take advantage of this.
548
549       To do this, you can write
550
551         use Sub::Quote;
552
553         use Moo;
554         use namespace::clean;
555
556         has foo => (
557           is => 'ro',
558           isa => quote_sub(q{ die "Not <3" unless $_[0] < 3 })
559         );
560
561       which will be inlined as
562
563         do {
564           local @_ = ($_[0]->{foo});
565           die "Not <3" unless $_[0] < 3;
566         }
567
568       or to avoid localizing @_,
569
570         has foo => (
571           is => 'ro',
572           isa => quote_sub(q{ my ($val) = @_; die "Not <3" unless $val < 3 })
573         );
574
575       which will be inlined as
576
577         do {
578           my ($val) = ($_[0]->{foo});
579           die "Not <3" unless $val < 3;
580         }
581
582       See Sub::Quote for more information, including how to pass lexical
583       captures that will also be compiled into the subroutine.
584

CLEANING UP IMPORTS

586       Moo will not clean up imported subroutines for you; you will have to do
587       that manually. The recommended way to do this is to declare your
588       imports first, then "use Moo", then "use namespace::clean".  Anything
589       imported before namespace::clean will be scrubbed.  Anything imported
590       or declared after will be still be available.
591
592         package Record;
593
594         use Digest::MD5 qw(md5_hex);
595
596         use Moo;
597         use namespace::clean;
598
599         has name => (is => 'ro', required => 1);
600         has id => (is => 'lazy');
601         sub _build_id {
602           my ($self) = @_;
603           return md5_hex($self->name);
604         }
605
606         1;
607
608       If you were to import "md5_hex" after namespace::clean you would be
609       able to call "->md5_hex()" on your "Record" instances (and it probably
610       wouldn't do what you expect!).
611
612       Moo::Roles behave slightly differently.  Since their methods are
613       composed into the consuming class, they can do a little more for you
614       automatically.  As long as you declare your imports before calling "use
615       Moo::Role", those imports and the ones Moo::Role itself provides will
616       not be composed into consuming classes so there's usually no need to
617       use namespace::clean.
618
619       On namespace::autoclean: Older versions of namespace::autoclean would
620       inflate Moo classes to full Moose classes, losing the benefits of Moo.
621       If you want to use namespace::autoclean with a Moo class, make sure you
622       are using version 0.16 or newer.
623

INCOMPATIBILITIES WITH MOOSE

625       There is no built-in type system.  "isa" is verified with a coderef; if
626       you need complex types, Type::Tiny can provide types, type libraries,
627       and will work seamlessly with both Moo and Moose.  Type::Tiny can be
628       considered the successor to MooseX::Types and provides a similar API,
629       so that you can write
630
631         use Types::Standard qw(Int);
632         has days_to_live => (is => 'ro', isa => Int);
633
634       "initializer" is not supported in core since the author considers it to
635       be a bad idea and Moose best practices recommend avoiding it. Meanwhile
636       "trigger" or "coerce" are more likely to be able to fulfill your needs.
637
638       There is no meta object.  If you need this level of complexity you need
639       Moose - Moo is small because it explicitly does not provide a
640       metaprotocol.  However, if you load Moose, then
641
642         Class::MOP::class_of($moo_class_or_role)
643
644       will return an appropriate metaclass pre-populated by Moo.
645
646       No support for "super", "override", "inner", or "augment" - the author
647       considers augment to be a bad idea, and override can be translated:
648
649         override foo => sub {
650           ...
651           super();
652           ...
653         };
654
655         around foo => sub {
656           my ($orig, $self) = (shift, shift);
657           ...
658           $self->$orig(@_);
659           ...
660         };
661
662       The "dump" method is not provided by default. The author suggests
663       loading Devel::Dwarn into "main::" (via "perl -MDevel::Dwarn ..." for
664       example) and using "$obj->$::Dwarn()" instead.
665
666       "default" only supports coderefs and plain scalars, because passing a
667       hash or array reference as a default is almost always incorrect since
668       the value is then shared between all objects using that default.
669
670       "lazy_build" is not supported; you are instead encouraged to use the
671       "is => 'lazy'" option supported by Moo and MooseX::AttributeShortcuts.
672
673       "auto_deref" is not supported since the author considers it a bad idea
674       and it has been considered best practice to avoid it for some time.
675
676       "documentation" will show up in a Moose metaclass created from your
677       class but is otherwise ignored. Then again, Moose ignores it as well,
678       so this is arguably not an incompatibility.
679
680       Since "coerce" does not require "isa" to be defined but Moose does
681       require it, the metaclass inflation for coerce alone is a trifle insane
682       and if you attempt to subtype the result will almost certainly break.
683
684       Handling of warnings: when you "use Moo" we enable strict and warnings,
685       in a similar way to Moose. The authors recommend the use of
686       "strictures", which enables FATAL warnings, and several extra pragmas
687       when used in development: indirect, multidimensional, and
688       bareword::filehandles.
689
690       Additionally, Moo supports a set of attribute option shortcuts intended
691       to reduce common boilerplate.  The set of shortcuts is the same as in
692       the Moose module MooseX::AttributeShortcuts as of its version 0.009+.
693       So if you:
694
695         package MyClass;
696         use Moo;
697         use strictures 2;
698
699       The nearest Moose invocation would be:
700
701         package MyClass;
702
703         use Moose;
704         use warnings FATAL => "all";
705         use MooseX::AttributeShortcuts;
706
707       or, if you're inheriting from a non-Moose class,
708
709         package MyClass;
710
711         use Moose;
712         use MooseX::NonMoose;
713         use warnings FATAL => "all";
714         use MooseX::AttributeShortcuts;
715
716       Finally, Moose requires you to call
717
718         __PACKAGE__->meta->make_immutable;
719
720       at the end of your class to get an inlined (i.e. not horribly slow)
721       constructor. Moo does it automatically the first time ->new is called
722       on your class. ("make_immutable" is a no-op in Moo to ease migration.)
723
724       An extension MooX::late exists to ease translating Moose packages to
725       Moo by providing a more Moose-like interface.
726

SUPPORT

728       Users' IRC: #moose on irc.perl.org
729
730       Development and contribution IRC: #web-simple on irc.perl.org
731
732       Bugtracker: <https://rt.cpan.org/Public/Dist/Display.html?Name=Moo>
733
734       Git repository: <git://github.com/moose/Moo.git>
735
736       Git browser: <https://github.com/moose/Moo>
737

AUTHOR

739       mst - Matt S. Trout (cpan:MSTROUT) <mst@shadowcat.co.uk>
740

CONTRIBUTORS

742       dg - David Leadbeater (cpan:DGL) <dgl@dgl.cx>
743
744       frew - Arthur Axel "fREW" Schmidt (cpan:FREW) <frioux@gmail.com>
745
746       hobbs - Andrew Rodland (cpan:ARODLAND) <arodland@cpan.org>
747
748       jnap - John Napiorkowski (cpan:JJNAPIORK) <jjn1056@yahoo.com>
749
750       ribasushi - Peter Rabbitson (cpan:RIBASUSHI) <ribasushi@cpan.org>
751
752       chip - Chip Salzenberg (cpan:CHIPS) <chip@pobox.com>
753
754       ajgb - Alex J. G. Burzyński (cpan:AJGB) <ajgb@cpan.org>
755
756       doy - Jesse Luehrs (cpan:DOY) <doy at tozt dot net>
757
758       perigrin - Chris Prather (cpan:PERIGRIN) <chris@prather.org>
759
760       Mithaldu - Christian Walde (cpan:MITHALDU)
761       <walde.christian@googlemail.com>
762
763       ilmari - Dagfinn Ilmari Mannsåker (cpan:ILMARI) <ilmari@ilmari.org>
764
765       tobyink - Toby Inkster (cpan:TOBYINK) <tobyink@cpan.org>
766
767       haarg - Graham Knop (cpan:HAARG) <haarg@cpan.org>
768
769       mattp - Matt Phillips (cpan:MATTP) <mattp@cpan.org>
770
771       bluefeet - Aran Deltac (cpan:BLUEFEET) <bluefeet@gmail.com>
772
773       bubaflub - Bob Kuo (cpan:BUBAFLUB) <bubaflub@cpan.org>
774
775       ether = Karen Etheridge (cpan:ETHER) <ether@cpan.org>
776
778       Copyright (c) 2010-2015 the Moo "AUTHOR" and "CONTRIBUTORS" as listed
779       above.
780

LICENSE

782       This library is free software and may be distributed under the same
783       terms as perl itself. See <http://dev.perl.org/licenses/>.
784
785
786
787perl v5.30.0                      2019-07-26                            Moo(3)
Impressum