This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.
OK, Moo is actually a rather nice little OO framework. It’s inspired by Moose but not a clone of it.
When Moo detects Moose has been loaded, it “inflates” all Moo classes and roles into Moose classes and roles, so Moo code integrates with Moose code perfectly. Because of this, and Moo’s very light memory and CPU footprint, many Moose-based projects are migrating to Moo. High profile migrations include Throwable, Message-Passing and MooseX-Role-Loggable.
Not all Moose-based projects are easy to port to Moo. Some require a high level of introspection and meta-hackery that only Moose can provide. But if Moo does seem to be a good fit for your project, switching to Moo is not as simple as dropping the “se” from your “use Moose” lines. There are a number of incompatibilities between the declarative syntaxes of Moo and Moose.
I’ve recently released MooX-late to help smooth over the differences and translate Moose code to Moo. Currently it handles:
- stringy type constraints, like
isa => "Str" - non-reference defaults, like
default => 1 - Moose’s
lazy_buildshortcut - Exporting the
blessedandconfessfunctions like Moose does
But I’d love to hear what other people think are the Moo annoyances. What is preventing you from porting simple classes and roles to Moo? What does Moose do for you that Moo does not? What features should I add to MooX-late?
