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

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

I kind of assume that it is already installed most everywhere.

There's your mistake. Other than its oddball testing dependencies, Moose is almost self-contained. Why break that, when it's trivial to just skip the relevant tests if Test::Exception isn't installed?

Just because lots of modules appear under Test::Exception in the CPANdeps tree (which, incidentally, you should link to as deps.cpantesters.org, not cpandeps.cantrell.org.uk) doesn't mean that they're only required because of Test::Exception.

Each distribution in the dependency tree is listed only once, so if, for example, Module::Build is required for both Test::Exception and Class::MOP, then it will only get listed under whichever 'parent' module I come across first when grovelling over the dependency tree.

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

Did you bother to click on the link? It looks like 7 of 17 dependencies are non-core, but maybe you and cpandeps have different definitions of "core."