I realise that this is not generally possible for all MooseX modules, particularly where the module delves into the meta class where Moose and Mouse differ.
But this question arose because sometimes a MooseX module doesn’t have an equivalent in the MouseX namespace, and I found that I could still use the MooseX module within my Mouse classes. But I want to ask this question in general, even if there is a MouseX equivalent available (let’s say I’m too lazy to install the MouseX one, or the MooseX version is more recent with new features).
For example, the following is valid:
package Foo;
use Mouse;
use MooseX::Types::Common::Numeric 'PositiveInt';
has 'bar' => (
is => 'rw',
isa => PositiveInt,
);
When I looked into MouseX::Types::Common::Numeric source it was almost an exact copy of MooseX::Types::Common::Numeric, though there were differences in MouseX::Types which is a dependency. Since it is perl code there is no particular performance benefit in using the MouseX module either.
So if we have a Mouse class and a choice of using equivalent MooseX and MouseX modules, what reasons would we have to choose the MouseX option? Why have the MouseX equivalent anyway?
btw, how should we relate to this with Any::Moose?
The point of using
Mouseis to have access to most features ofMoosewhile eliminating its expensive startup time and Yggdrasil-like dependency tree. If you’re using aMooseXmodule with it, that module brings inMoose, or at leastMoose::Exporter/Moose::Role, and you’ve then eliminated the benefits ofMouse. Observe:So fast! But then:
So slow. But if those startup times don’t matter for what you’re doing, You shouldn’t even be bothering with
Mouseto begin with.Any::Mooseexists to allow aMoose-oriented module to useMouseunlessMooseis already loaded, in which case it’ll just use that.