Moose vs. MooseX::Declare

Question

POSTLUDE

MooseX::Declare would no longer be recommended by anyone as it relies on Devel::Declare which served its purpose but is itself obsolete. At this point if anyone wants MX::D they should look at Moops

ORIGINAL

Assuming I already have a decent knowledge of old-style Perl OO, and assuming I am going to write some new code in some flavor of Moose (yes, I understand there is a performance hit), I was wondering if deeper down either rabbit hole, am I going to wish that I had chosen the other path? Could you SO-monks enlighten me with the relative merits of Moose vs. MooseX::Declare (or some other?). Also how interchangeable they are, one for one class and the other for another, should I choose to switch.

(p.s. I would be ok cw-ing this question, however I think a well formed answer might be able to avoid subjectivity)

Rumelia

peregrin's answer has a very nice list of items so I have marked it "correct", however please post additional items/gotchas etc if you have them! – Rumelia

It's important to note that Moose's performance hit is only on startup. If you're writing a persistent program it's actually very fast. – Chiller

Answer 1

MooseX::Declare is basically a sugar-layer of syntax over Moose. They are, for everything past the parser, identical in what they produce. MooseX::Declare just produces a lot more of it, with a lot less writing.

Speaking as someone who enjoys the syntax of MooseX::Declare but still prefers to write all of my code in plain Moose, the tradeoffs are mostly on the development & maintainability side.

The basic list of items of note when comparing them:

• MooseX::Declare has much more concise syntax. Things that take several hundred lines in plain old perl objects (POPO?), may take 50 lines in Moose, may take 30 lines in MooseX::Declare. The code from MooseX::Declare is to me more readable and elegant as well.

• MooseX::Declare means you have MooseX::Types and MooseX::Method::Signatures for free. This leads to the very elegant method foo(Bar $bar, Baz $baz) { ... } syntax that caused people to come back to Perl after several years in Ruby.

• A downside to MooseX::Declare is that some of the error messages are much more cryptic than Moose. The error to a TypeConstraint validation failure may happen several layers deep in MooseX::Types::Structured and getting from there to where in your code you broke it can be difficult for people new to the system. Moose has this problem too, but to a lesser degree.

• The places where the dragons hide in MooseX::Declare can be subtly different than where they hide in Moose. MooseX::Declare puts in an effort to walk around known Moose issues ( the timing of with() for example) but introduces some new places to be aware of. MooseX::Types for example have a wholly different set of problems from Moose's native Stringy types[^1].

• MooseX::Declare has yet another performance hit. This is known to the MooseX::Declare developers and people are working on it (for several values of working I believe).

• MooseX::Declare adds more dependencies to Moose. I add this one because people complain already about Moose's dependency list which is around 20 modules. MooseX::Declare adds around another 5 direct dependencies on top of that. The total list however according to http://deps.cpantesters.org/ is Moose 27, MooseX::Declare 91.

If you're willing to go with MooseX::Declare, the best part is you can swap between them at the per-class level. You need not pick one over the over in a project. If this class is better in Moose because of Performance needs, or it's being maintained by Junior programmers, or being installed on a more tightly controlled system. You can do that. If that class can benefit from the extra clarity of the MooseX::Declare syntax you can do that too.

Hope this helps answer the question.

[^1]: Some say fewer, some say more. Honestly the Moose core developers are still arguing this one, and there is no right answer.

Training

Honestly I was surprised nobody else answered. Usually by the time I see it ether and several others have commented. And I dont' care about the karma or wiffy or whatever it is, if you notice I only answer the Moose questions. I care about Moose ;) – Training

Thanks again! You say that MooseX::Types comes along for free, does this mean I can somehow not have to do class Fully::Qualified::Class::Name {? Is there some good example of this? – Rumelia

@Joel MooseX::Types is different from the class declaration. You'll stll need class Fully::Qualified::Name {...} when declaring a class. – Training

The performance hit for MooseX::Method::Signatures is appalling, slowing down method calls by 40x. This cost is paid just by using the method keyword whether or not any arguments or type checking is used. In contrast, Method::Signatures has almost no performance hit and it has alpha support for Moose (or Mouse) types. search.cpan.org/dist/Method-Signatures There's a mod of MooseX::Declare in the works to use this instead. – Communal

I remembered this and thought I should post: the mod is Method::Signatures::Modifiers! – Rumelia

Answer 2

One minor aspect that may interest you, and I may as well be interested by an answer to this : the main problem I had with MooseX::Declare, which was important in my specific case, was that I was unable to pack my application as an executable, neither with PAR::Packer nor ActiveState PerlApp.

I then used https://github.com/komarov/undeclare/blob/master/undeclare.pl to go back to Moose code.

Pretense

Answer 3

As written above other problems with MooseX::Declare: - terrible error messages ( really, useless. unless you use Method::Signatures::Modifiers ) - performance hit ( as You have noted ), but in my opinion not small. ( we profiled some big real-life apps ) - problem with TryCatch ( if U use that, see: https://rt.cpan.org/Public/Bug/Display.html?id=82618 ) - some incompatibilities in mixed ( MooseX - non-Moose environment, eg. failed $VERSION check )

If You do not need the 'syntactic sugar' of MooseX, do not use it. Depending on the task You are into, I'd use from 'bottom-to-top', eg. 1. Mouse+Mehod::Signatures 2. Moose 3. then perhaps MooseX

depending on what you want.

Upgrading is not too complicated in this order. However, if You come to the point that You really need MooseX, I'd rather suggest You looking for some other, OO-wise developed language that offer most of the features in-box ( eg. horribile dictu Ruby or Python ), and those, that are not found, You perhaps you can live without.

Sebastiansebastiano

The world progresses quickly. I no longer use MooseX::Declare, but recently a new competitor was introduced Moops which I hope to evaluate soon. Modern Perl is in a (good) state of flux, ironing out what will be the future agreed-upon syntax of Modern OO Perl. Its exciting really! – Rumelia

Answer 4

If You really want Moose, consider a bottom-to-top approach starting with the less sugar. I prefer using Mouse + Method::Signatures first. My scenario is that I am sitting on the backend where we need very few objects, shallow hierarchy, but sometimes fast accessors - then we can still fall back to XSAccessor. Mouse+Method Signatures seem to be a rather good compromise between syntactic help and speed. If my design really needs more, then simply upgrade to Moose. I can confirm the speed penalty with MooseX::Declare not only with simple accessor benchmarks ( https://metacpan.org/pod/App::Benchmark::Accessors ), but also in real-life application. This combined with cryptic error messages rules MooseX::Declare out.

Gladiate

thanks for the answer, but indeed the question is ancient and obsolete. MooseX::Declare would no longer be recommended by anyone as it relies on Devel::Declare which served its purpose but is itself obsolete. At this point if anyone wants MX::D they should look at Moops – Rumelia