Shadowcat Systems Limited

sufficiently advanced technology

Telephone 01524 842155
Email: info(at)

Sat Mar 16 21:30:00 2013

Moo 1.1 is here

So, what does this new release give you?

Scalar defaults

has name => (is => 'ro', default => "Darkstar");

will now work - we still disallow {} and [] in defaults because defaults aren't copied so those would be a footgun (plus Stevan apparently realised he agreed with me about that in 2006 and I just didn't notice Moose stopping supporting it :).

Build me a builder

has dbh => (is => 'lazy', builder => sub {
  DBI->connect($_[0]->dsn, $_[0]->user, $_[0]->password, { RaiseError => 1 })

not only uses that builder to construct the attribute, but installs it into _build_dbh for you - so you can use method modifiers in subclasses and roles to affect it.

Predicated on convention

has optional_thing => (is => 'ro', predicate => 1);

will now generate a has_optional_thing for you, so you don't need to repeat the attribute names. This also works for builder, clearer and trigger - see the documentation for details.

Don't be late with your port

use MooX 'late';

will load Moo and then apply the MooX::late extension - which does its best to handle most of the bits of Moose surface syntax that Moo doesn't, including string type names, override and augment, and lazy_build.

Admittedly, the author promises it will never do more than seven things ... but I'm sure you'll be able to tempt him.

A bundle of bug fixes

We've fixed a bunch of edge cases as well - Moo now screams loudly if you try and extend a role, or overwrite an existing method from an accessor; we've fixed an interoperability bug with Moose wherein it can forget about a method even when you explicitly added it via the metaclass (and some other bits and pieces); and you can now pass a role name to handles without loading the role yourself.

Whither next?

Work still needs to be done to fix edge cases in composition in Role::Tiny, and there are bound to be more bugs.

Perhaps more interestingly, I'm planning to work on a Moo::Compile that will allow you to ship Moo-using code that doesn't depend on Moo.

Plus Dave Rolsky's work on a Moose-independent rich type system is looking promising, and once that's complete I imagine we'll integrate it somehow.

CPAN (re)portage

In the mean time, rjbs' Throwable is now a Moo based dist, as is Email::Sender - which enables the use of both of those libraries in CPAN modules whose users are sensitive to startup times and/or transitive dependencies. I imagine we'll see more CPAN modules move over time, if nothing else because porting from Moose to Moo is generally more fun than arguing with people who don't want to use Moose :)

In summary

Moo 1.1 is shinier, stabler and more pleasant than ever before - and almost all of the code between 1.0 and here was written by contributors with me just helping out with the odd bit of design advice. sniff yet another of my babies is growing up :)

Thanks very much to everybody who helped. Enjoy!

-- mst, out.