Actually Mouse should really only be used in cases when it is a hard requirement to use less memory/cpu/dependencies. We are trying to actively discourage people from using it for convenience sake, since we hope by the end of this year to have completely removed the need for it to exist at all.

we hope by the end of this year to have completely removed the need for it to exist at all.

Can you elaborate on what need you see for it to exist and how you aim to remove it? Depending on how you define the terms, this statement could mean anything from "we're working to improve Moose's speed" to "Moose is replacing blessed hashes in /usr/bin/perl".

Can you elaborate on what need you see for it to exist and how you aim to remove it?

Mouse exists because Sartak wanted to use Moose for a command line program that needed to start up fast. Moose has a well known issue with startup time, so it just was not an option in this case. So Sartak pulled out a Moose-clone he was playing around with (to help learn how Moose worked he says) and so Mouse was born. It needs to exist for situations like this, where Moose is just not capable of fitting.

We aim to remove the need for Mouse by fixing the issues in Moose that Mouse addresses. Matt Trout, Yuval Kogman, Florian Ragwitz and others spent a fair portion of the Nordic Perl Workshop refactoring the Moose internals to make way for Matt's Antlers project. Antlers plans to cache all meta-objects that Moose creates as well as all the accessor code generation that Moose does. Then only load up the meta-object when absolutely necessary. This should result in a faster startup time because of less CPU usage and then less memory usage overall (unless you call ->meta, in which case then you will need to load that meta-object). Florian and Yuval are also working on another project called Moose::XS which will replace much of the generated accessors (all perl code that must get string-evaled (big performance hit there)) with leaner XS versions. This alone should go a long ways to reducing the startup speed (less string-eval means less CPU) and should help some with memory (the core accessors can be re-used rather then having to eval a new method into life each time).

These projects are still in the early stages, but they are based on research we have been doing for well over a year now so we are pretty confident in them. Hopefully much progress will be made at the various conference hackathons this year and (as I said above) we hope to have something working and ready for production use by years end (I would say christmas, but perl 6 has already taken that).

-stvn

I won't speak to the performance issue, but you could cut down the dependency insanity by not requiring Test::Exception. Is your Test Flavor of the Day worth 17 dependencies?

Is your Test Flavor of the Day worth 17 dependencies?

Short answer, No.

Long answer, I have been using Test::Exception for many years and I honestly don't give it a second thought. I also do not think of it as a "Test Flavor of the Day", but more "the right way to test exception handling with perl" (is there even another one short of rolling my own with eval ?). It is used in a lot of cpan modules already and I kind of assume that it is already installed most everywhere.

-stvn

Where do you see that Test::Exception has 17 dependencies? Its only non-core dependency is Sub::Uplevel, which has no non-core dependencies.