A slim-line Moose-alike without the costs and features most people don't need (plus Moose compatibility if it turns out you did); easy to sell to folks concerned about the overhead inherent to Moose. Very much simplified my object-heavy code.
As an experiment in reimplementing Moose, this is a fine module. If Mouse didn't exist, I would recommend this module for people who want a lighter Moose.
As a faster, lighter alternative to Moose, Moo falls short of Mouse.
Both don't require XS.
It has less features than Mouse.
It doesn't have Moose types (but they're available via MooX::Types::MooseLike).
Its type system is incompatible with Moose (MooX::Types::MooseLike is available, but stock Moo types are not forward compatible).
It's slower than Mouse (XS Mouse for sure).
It has required dependencies, unlike Mouse.
One thing Moo has going for it, it is meta class compatible with Moose. That is, Moo classes and roles can extend Moose classes and roles and vice versa. If Moo is measurably faster than Moose, this allows you to write some performance sensitive classes in Moo but still cleanly interoperate with the rest of your Moose classes. Mouse will not do that.
For my use, the few advantages don't merit the loss of speed and features and the additional dependencies. The incompatible type system hinders easily upgrading from Moo to Mouse or Moose, though MooX::Types::MooseLike mitigates that.
That's how things stand now. These things change with every version.
NOTE: This was originally a review of 0.009012. I've updated the facts for the latest version.
This module allows us to use the best practices inspired by Moose, for applications that are very critical to the speed and memory usage.
This is a quick response to dirk's review. Although the documentation may make the list of missing features sound like they're just mst's whims (and some probably are), there is sound reasoning behind many of them.
If you read Moose::Manual::BestPractices you'll see:
* Avoid lazy_build
* Don't use the initializer feature
* Use Moose::Meta::Attribute::Native traits instead of auto_deref
And, directly quoting from Moose's author regarding augment/inner: "Thankfully, only a small percentage of people actually grok this feature and of those people only a handful of them are crazy enough to try and use it."
Augment/inner is hard to implement right; there are serious bugs lurking under the surface of Moose's implementation. It wouldn't be especially valuable for Moo to add another broken augment/inner implementation to CPAN.
Moo is not compatible with Moose in the same sense that Mouse is, where you can just replace "use Moose" with "use Mouse" and almost everything Just Works.
Moo is compatible in a different way - Moo classes can consume Moose roles; Moose classes can consume Moo roles; Moose classes can extend Moo classes; etc. In my opinion this is a more useful kind of compatibility.
I like the overall idea of Moo, but the author claims to try to support Moose compatibility where technically possible, but then creates arbitrary incompatibilities because of personal preference and not because of technical limitations. These are the direct quotes from the pod:
- "initializer is not supported in core since the author considers it to be a bad idea",
- "No support for super, override, inner, or augment - the author considers augment to be a bad idea",
- "default" only supports coderefs, because doing otherwise is usually a mistake anyway",
- "lazy_build is not supported; you are instead encouraged to use the is => 'lazy'",
- "auto_deref is not supported since the author considers it a bad idea."
Moo is very adept at providing a very lightweight and quick way to provide 'Modern' object oriented interface. While it is true that Moo itself has dependencies, I have observed that they are fairly lightweight.
Sometimes, the lack of certain features in itself is a feature, and I think Moo expresses this very well.
Of course, the lack of features.. is well.. a lack of features. But for what it's worth, I find dealing with Moo's "lack" of features easier than dealing with M[ou]ose's larger featureset.
Also, I personally find Moo's stack traces are easier to read and understand.
Last week I ported an application from Mouse (Any::Moose) to Moo. Went without a hitch (well I did replace "with 'X', 'Y', 'Z';" to "with 'X'; with 'Y'; with 'Z';" as instructed in the Moo documentation). Startup time decreased significantly. Planning to move every Moose apps to Moo. Splendid!
1 hidden unhelpful review