Let me first say that I am biased being the original author of Moose. However, let me also say that I am good friends with the author of Mouse and that he is also one of the core members of the Moose cabal. Moose and Mouse are not in competition with one another, and the primary motivation behind Mouse has always been to serve as a stop-gap measure to get Moose-ey goodness in places where a Moose would never fit.

Now, that said, let me tell you why you should use Moose.

First off, the reasons to use Mouse are as follows:

• You have hard requirements for fast startup time. Examples of this are: (some) command line apps, vanilla CGI scripts (hello, 1997 called they want their technology back) and scripts that have hard time requirements (you must execute in this 30 second window, etc etc)
• You have hard requirements for minimizing memory usage.
• You have issues with module/application deployment, such as IT staff that don't like to install from CPAN or some kind of secure/restricted environment.

• Moose is just over 3 years old now and has been running in several non-trivial production applications for that entire time. Mouse on the other hand is not even a year old yet and while it is used very seriously by a number of people, it just isn't as battle tested as Moose is.
• Moose's startup speed and memory consumption issues will eventually get solved at which point Mouse will very likely be deprecated ^*. Like I said above, Mouse is a stop-gap measure, not a long term solution.
• Moose has many MooseX:: modules to extend Moose itself, many of which would not be possible to do with Mouse. While there has been a few MouseX:: modules uploaded recently, they are mostly just Mouse-ifications of MooseX:: modules.
• Moose brings with it all the power of metaprogramming through the MOP (Class::MOP to be exact). Even if you don't use the MOP that much, just having it there when you need it can be really useful.

As we will have some long-running processes we cannot tolerate any memory-leaks and the like.

As far as I know neither Mouse nor Moose have memory leaks. Some older leak detection modules will claim that Moose does, but those are the meta-objects that power Moose and not leaks.

My current feeling (I have not done much testing yet) is that the run-time performance of Moose will not be very much different from Mouse ...

This is true, I think Mouse right now is a little bit faster then Moose but not by enough that your app would likely notice (unless you app is a ray tracer or something like that). This also may change soon as there is lots of work going on to XS-ify the Moose accessors.

So in conclusion, ... use Moose :)

* - The best way to future proof against the eventual deprecation of Mouse is to to use Any::Moose.

As author of Mouse, I agree with almost everything stevan is saying. I disagree with his third reason for using Mouse. If you can install even one module on CPAN, you can probably install the ~16 dependencies of Moose.

Use Moose!

I've been pondering this question for days whilst following along on this thread, and other recent Moose threads.

Let me say up front that I think Moose is incredibly clever, complete and well supported and maintained code. But here's the question that I've been asking myself for most of the last 3 years, and for which I yet to find a satisfactory answer to when I've looked arounnd.

What, besides declarative syntax and auto-generated accessors--which are both available at far less cost from other modules--does Moose buy the application programmer, that makes it worth the not inconsiderable costs?

For (my) best interest, I'm not looking for a straight list of features--which I have found around. I'm more looking for examples of how people have used those features, to implement something that they would have had to implement anyway, had they used some other OO framework. But which Moose made significantly simpler to implement and/or significantly more effective.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

What, besides declarative syntax and auto-generated accessors--which are both available at far less cost from other modules--does Moose buy the application programmer, that makes it worth the not inconsiderable costs?

Moose is much more than "declarative syntax and auto-generated accessors" it also provides:

• A base class (Moose::Object) that provides a sensible default constructor and controlled object initialization (through BUILD/BUILDALL) and just as controlled destruction (through DEMOLISH/DEMOLISHALL). This may not seem like much, but is eliminates a whole lot of boilerplate.
• A formal system for managing object attributes/properties/slots that allows the programmer to not have to worry about any details such as inheritance, etc. (basically this means you don't have to remember to call SUPER::new in your constructor and/or worry about initialization order).
• A complete role system, which provides very useful ways in which you can re-use code that would otherwise not be as easily re-used. (Really once you get hang of roles, you will love them).
• A powerful AOP-ish set of method modifiers (before/after/around).
• A powerful and extensible type-constraint system.
• A set of very useful extensions in the MooseX:: namespace.
• A complete meta-programming environment, which means that everything above is introspectable, manipulatable and extensible.
• ... and lastly, all the above components are built on a single platform and is guaranteed to always work well together (this fact should not be underestimated).
Basically, everything any other modern object oriented language would give you (and then some).

For (my) best interest, I'm not looking for a straight list of features--which I have found around.

Okay, the "list of features" not what you want, here is a "list of benefits" for Moose.

• Less testing - Why test what Moose already tests? Because Moose writes a lot of code for you and we very thoroughly test that code writing, there is no need to test simple things like accessors and such.
• Less boilerplate - You can get up and running with a simple package Foo; use Moose; and Foo is now a full fledged class instead of just a plain perl package. One more line package Foo; use Moose; has baz => (is => 'ro', isa => 'Int'); and you can have access controlled attributes which have type checking and a constructor that accepts named parameters.
• Less Tedium - Moose takes care of a whole lot of very repetitive and tedious tasks for you (managing inheritance, generating accessors, etc). By taking care of the boring bits for you, Moose eliminates a whole class of typo errors and other hard-to-track-down problems.
• More Consistency - Moose respects the Perl motto of TIMTOWTDI, but does it's best to inject a level of consistency to the otherwise chaotic world of Perl OOP. The results of this is that it becomes easier to do basic OO things like inheritance because you can be sure of how the extended class will behave. Of course in isolation this is not that interesting, but when you realize this doesn't just apply within your project, but applies to anything else written in Moose. Which means that you no longer need to wonder if CPAN modules will be amenable to subclassing, if they are written in Moose, it should Just Work.
• More Readability - This is not always true at first, but once you get familiar with the Moose way of doing things, it is very easy to pick up any Moose code and understand it in a relatively short period of time. No longer do you need to figure out how they have implemented their OO or what kind of accessors they are using, etc etc etc.
• More Maintainability - With Moose you write less code, so therefore you have less to maintain. This leads back again to the point about consistency, because consistent code is easier to maintain, especially when you program in the large.

I'm more looking for examples of how people have used those features, to implement something that they would have had to implement anyway, had they used some other OO framework.

Here are 382 examples :)

Honestly, I think perhaps the best way to answer this question is to try out Moose for yourself. You have been dancing around Moose for years now and (as best I know) have not just sat down and tried to solve a problem with it. There is no better way to know if Moose is useful for you then to just give it a try.

-stvn

Thanks a lot for all replies - we'll probably go with Moose now.

I have one more question:

In a previous project I've used Class::Std and I quite like the strong encapsulation for object-attributes it provides.

I just did some (very basic) playing around with Moose and wonder if there is any way to encapsulate object-attributes as well or if with Moose no access-control is possible.

For example I was very surprised that you could do the following:

<code>

use strict;

package Hubba;
use Moose;

has 'hubba' => ( is => "rw", isa => 'Int' );

package main;
no Moose;

my $h = Hubba->new;

$h->{hubba} = "Bubba";

print $h->hubba

</code>

This actually prints "Bubba". In this example I declare a "hubba"-attribute of a "Hubba"-class to be of type Int, but still it is possible to subvert the type-system by accessing the attribute directly (or am I doing something wrong?)

I don't think all of this will be a major concern for us, but still I would prefer stronger encapsulation - is that possible with Moose (or can you mix Moose and Class::Std)?

Many thanks!

Moose does not attempt to solve this, mostly because we see it as a social problem rather then a technical problem.

If a co-worker writes code that accesses the underly HASH ref then they are breaking encapsulation (as well as general community coding standards). Once you discover this violation, you should talk to that person and explain why they shouldn't do it. If said co-worker continues to do this, then they should likely be fired or at least disciplined.

Encapsulation is just a concept, something you can use to help write better code with. Encapsulation is not about completely preventing access to slots, but about providing clean and controlled ways to access slots. Moose accessors provide exactly that, a clean, consistent and controlled way to access your object's slots. What Class::Std (and all the other Inside-Out object systems) do is really just obsfucate slot access, an enterprising hacker can easily get past that encapsulation using modules like B and PadWalker.

... can you mix Moose and Class::Std?

Not at all, they are two conflicting systems.

-stvn

You may want to look at MooseX::InsideOut?