1Moo(3) User Contributed Perl Documentation Moo(3)
2
6 Moo - Minimalist Object Orientation (with Moose compatibility)
7
9 package Cat::Food;
10 use Moo;
12 use strictures 2;
13 use namespace::clean;
14 sub feed_lion {
16 my $self = shift;
17 my $amount = shift || 1;
18 $self->pounds( $self->pounds - $amount );
20 }
21 has taste => (
23 is => 'ro',
24 );
25 has brand => (
27 is => 'ro',
28 isa => sub {
29 die "Only SWEET-TREATZ supported!" unless $_[0] eq 'SWEET-TREATZ'
30 },
31 );
32 has pounds => (
34 is => 'rw',
35 isa => sub { die "$_[0] is too much cat food!" unless $_[0] < 15 },
36 );
37 1;
39 And elsewhere:
41 my $full = Cat::Food->new(
43 taste => 'DELICIOUS.',
44 brand => 'SWEET-TREATZ',
45 pounds => 10,
46 );
47 $full->feed_lion;
49 say $full->pounds;
51
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 "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 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 For a full list of the minor differences between Moose and Moo's
68 surface syntax, see "INCOMPATIBILITIES WITH MOOSE".
69
71 If you want a full object system with a rich Metaprotocol, Moose is
72 already wonderful.
73 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 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 "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 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
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 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 Extending a Moose class or consuming a Moose::Role will also work.
101 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 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 If you need to disable the metaclass creation, add:
115 no Moo::sification;
117 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
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
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 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 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 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
150 Moo provides several methods to any class using it.
151 new
153 Foo::Bar->new( attr1 => 3 );
154 or
156 Foo::Bar->new({ attr1 => 3 });
158 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 does
164 if ($foo->does('Some::Role1')) {
165 ...
166 }
167 Returns true if the object composes in the passed role.
169 DOES
171 if ($foo->DOES('Some::Role1') || $foo->DOES('Some::Class1')) {
172 ...
173 }
174 Similar to "does", but will also return true for both composed roles
176 and superclasses.
177 meta
179 my $meta = Foo::Bar->meta;
180 my @methods = $meta->get_method_list;
181 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
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 BUILDARGS
196 around BUILDARGS => sub {
197 my ( $orig, $class, @args ) = @_;
198 return { attr1 => $args[0] }
200 if @args == 1 && !ref $args[0];
201 return $class->$orig(@args);
203 };
204 Foo::Bar->new( 3 );
206 This class method is used to transform the arguments to "new" into a
208 hash reference of attribute values.
209 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 You can override this method in your class to handle other types of
215 options passed to the constructor.
216 This method should always return a hash reference of named options.
218 FOREIGNBUILDARGS
220 sub FOREIGNBUILDARGS {
221 my ( $class, $options ) = @_;
222 return $options->{foo};
223 }
224 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 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 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 DEMOLISH
246 sub DEMOLISH {
247 my ($self, $in_global_destruction) = @_;
248 ...
249 }
250 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 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
264 extends
265 extends 'Parent::Class';
266 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 Calling extends more than once will REPLACE your superclasses, not add
273 to them like 'use base' would.
274 with
276 with 'Some::Role1';
277 or
279 with 'Some::Role1', 'Some::Role2';
281 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 has
288 has attr => (
289 is => 'ro',
290 );
291 Declares an attribute for the class.
293 package Foo;
295 use Moo;
296 has 'attr' => (
297 is => 'ro'
298 );
299 package Bar;
301 use Moo;
302 extends 'Foo';
303 has '+attr' => (
304 default => sub { "blah" },
305 );
306 Using the "+" notation, it's possible to override an attribute.
308 has [qw(attr1 attr2 attr3)] => (
310 is => 'ro',
311 );
312 Using an arrayref with multiple attribute names, it's possible to
314 declare multiple attributes with the same options.
315 The options for "has" are as follows:
317 "is"
319 required, may be "ro", "lazy", "rwp" or "rw".
320 "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 "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 "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 "rw" stands for "read-write" and generates a normal getter/setter by
341 defaulting the "accessor" to the name of the attribute specified.
342 "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 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 Note that the return value for "isa" is discarded. Only if the sub
355 dies does type validation fail.
356 Sub::Quote aware
358 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 If you want Moose compatible or MooseX::Types style named types, look
367 at Type::Tiny.
368 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 $Moo::HandleMoose::TYPE_MAP{$isa_coderef} = sub {
374 require MooseX::Types::Something;
375 return MooseX::Types::Something::TypeName();
376 };
377 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 "coerce"
383 Takes a coderef which is meant to coerce the attribute. The basic
384 idea is to do something like the following:
385 coerce => sub {
387 $_[0] % 2 ? $_[0] : $_[0] + 1
388 },
389 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 Sub::Quote aware
397 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 "handles"
402 Takes a string
403 handles => 'RobotRole'
405 Where "RobotRole" is a role that defines an interface which becomes
407 the list of methods to handle.
408 Takes a list of methods
410 handles => [ qw( one two ) ]
412 Takes a hashref
414 handles => {
416 un => 'one',
417 }
418 "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 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 Note that Moose also passes the old value, if any; this feature is
430 not yet supported.
431 Sub::Quote aware
433 "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 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 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 Sub::Quote aware
450 "predicate"
452 Takes a method name which will return true if an attribute has a
453 value.
454 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 "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 $default->($self);
465 Moo will call
467 $self->$builder;
469 The following features come from MooseX::AttributeShortcuts:
471 If you set this to just 1, the builder is automatically named
473 "_build_${attr_name}".
474 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 "clearer"
480 Takes a method name which will clear the attribute.
481 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 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 "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 "required"
497 Boolean. Set this if the attribute must be passed on object
498 instantiation.
499 "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 "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 "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 "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 "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 before
527 before foo => sub { ... };
528 See "before method(s) => sub { ... };" in Class::Method::Modifiers for
530 full documentation.
531 around
533 around foo => sub { ... };
534 See "around method(s) => sub { ... };" in Class::Method::Modifiers for
536 full documentation.
537 after
539 after foo => sub { ... };
540 See "after method(s) => sub { ... };" in Class::Method::Modifiers for
542 full documentation.
543
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 To do this, you can write
550 use Sub::Quote;
552 use Moo;
554 use namespace::clean;
555 has foo => (
557 is => 'ro',
558 isa => quote_sub(q{ die "Not <3" unless $_[0] < 3 })
559 );
560 which will be inlined as
562 do {
564 local @_ = ($_[0]->{foo});
565 die "Not <3" unless $_[0] < 3;
566 }
567 or to avoid localizing @_,
569 has foo => (
571 is => 'ro',
572 isa => quote_sub(q{ my ($val) = @_; die "Not <3" unless $val < 3 })
573 );
574 which will be inlined as
576 do {
578 my ($val) = ($_[0]->{foo});
579 die "Not <3" unless $val < 3;
580 }
581 See Sub::Quote for more information, including how to pass lexical
583 captures that will also be compiled into the subroutine.
584
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 package Record;
593 use Digest::MD5 qw(md5_hex);
595 use Moo;
597 use namespace::clean;
598 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 1;
607 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 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 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
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 use Types::Standard qw(Int);
632 has days_to_live => (is => 'ro', isa => Int);
633 "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 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 Class::MOP::class_of($moo_class_or_role)
643 will return an appropriate metaclass pre-populated by Moo.
645 No support for "super", "override", "inner", or "augment" - the author
647 considers augment to be a bad idea, and override can be translated:
648 override foo => sub {
650 ...
651 super();
652 ...
653 };
654 around foo => sub {
656 my ($orig, $self) = (shift, shift);
657 ...
658 $self->$orig(@_);
659 ...
660 };
661 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 "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 "lazy_build" is not supported; you are instead encouraged to use the
671 "is => 'lazy'" option supported by Moo and MooseX::AttributeShortcuts.
672 "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 "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 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 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 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 package MyClass;
696 use Moo;
697 use strictures 2;
698 The nearest Moose invocation would be:
700 package MyClass;
702 use Moose;
704 use warnings FATAL => "all";
705 use MooseX::AttributeShortcuts;
706 or, if you're inheriting from a non-Moose class,
708 package MyClass;
710 use Moose;
712 use MooseX::NonMoose;
713 use warnings FATAL => "all";
714 use MooseX::AttributeShortcuts;
715 Finally, Moose requires you to call
717 __PACKAGE__->meta->make_immutable;
719 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 An extension MooX::late exists to ease translating Moose packages to
725 Moo by providing a more Moose-like interface.
726
728 Users' IRC: #moose on irc.perl.org
729 Development and contribution IRC: #web-simple on irc.perl.org
731 Bugtracker: <https://rt.cpan.org/Public/Dist/Display.html?Name=Moo>
733 Git repository: <git://github.com/moose/Moo.git>
735 Git browser: <https://github.com/moose/Moo>
737
739 mst - Matt S. Trout (cpan:MSTROUT) <mst@shadowcat.co.uk>
740
742 dg - David Leadbeater (cpan:DGL) <dgl@dgl.cx>
743 frew - Arthur Axel "fREW" Schmidt (cpan:FREW) <frioux@gmail.com>
745 hobbs - Andrew Rodland (cpan:ARODLAND) <arodland@cpan.org>
747 jnap - John Napiorkowski (cpan:JJNAPIORK) <jjn1056@yahoo.com>
749 ribasushi - Peter Rabbitson (cpan:RIBASUSHI) <ribasushi@cpan.org>
751 chip - Chip Salzenberg (cpan:CHIPS) <chip@pobox.com>
753 ajgb - Alex J. G. Burzyński (cpan:AJGB) <ajgb@cpan.org>
755 doy - Jesse Luehrs (cpan:DOY) <doy at tozt dot net>
757 perigrin - Chris Prather (cpan:PERIGRIN) <chris@prather.org>
759 Mithaldu - Christian Walde (cpan:MITHALDU)
761 <walde.christian@googlemail.com>
762 ilmari - Dagfinn Ilmari Mannsåker (cpan:ILMARI) <ilmari@ilmari.org>
764 tobyink - Toby Inkster (cpan:TOBYINK) <tobyink@cpan.org>
766 haarg - Graham Knop (cpan:HAARG) <haarg@cpan.org>
768 mattp - Matt Phillips (cpan:MATTP) <mattp@cpan.org>
770 bluefeet - Aran Deltac (cpan:BLUEFEET) <bluefeet@gmail.com>
772 bubaflub - Bob Kuo (cpan:BUBAFLUB) <bubaflub@cpan.org>
774 ether = Karen Etheridge (cpan:ETHER) <ether@cpan.org>
776
778 Copyright (c) 2010-2015 the Moo "AUTHOR" and "CONTRIBUTORS" as listed
779 above.
780
782 This library is free software and may be distributed under the same
783 terms as perl itself. See <http://dev.perl.org/licenses/>.
784perl v5.30.0 2019-07-26 Moo(3)