MooseX::Types - because typing is hard

Moose is awesome; we all know that. However
since types are just as global as package names, it's very easy to run into
trouble with namespacing - either you use short names, and risk clashes with
other packages, or you use fully namespaced names, and incur a lot of extra
typing. Or ... there's a third way, but first, a little background.

can't take advantage of the aliased magic because the type name is a string.
Well, we could do

has frobbers => (is => 'ro', isa => 'HashRef['.Frobnicator.']');

or

has frobbers => (is => 'ro', isa => "HashRef[${\Frobnicator}]");

but then the next person to try and maintain this code is significantly
likely to hunt you down and punch you repeatedly in the genitals, and
rightly so.

Enter the MooseX

I said MooseX. Leave the cow alone.

MooseX::Types is a system for building
namespaced, re-usable type libraries that then export subroutines returning
the constraint, much like aliased does for class names (although MooseX::Types
returns an object rather than a string).

Better still, there's a bunch of already pre-existing ones in that namespace,
including a Moose one that provides subroutine forms of the built-in type
constraints - including parameterizable versions of types like HashRef that
provide the same syntax as the string form.

So, the first thing we can do is to use
MooseX::Types::Moose to get a
subroutine style HashRef that can handle this a bit better -

Alarums and coercions

Next problem - coercions. The thing about Moose coercions is that they're
attached to the type (a fact that sometimes makes me sad, but is usually
perfectly workable), so ideally you need to add them to your own type.

None of the core Moose types have coercions. None of your core-like
ones should either.

For added comedy value, it will throw an exception ... sometimes. This is
because types should be defined before they're used - strictly, this code
should be preceded by

class_type 'MyCompany::MyProject::SomethingOrOther::Frobnicator';

but since 'use Moose' in your class does that anyway, if the class has
already been loaded whne you call coerce, it all appears to be fine. Then
your loading order changes and BOOM. I love bugs like this; they make
"No boom today? Boom tomorrow. There's always boom tomorrow." seem
delightfully predictable.

But wait! There's more! What we almost certainly really want is to handle
an ArrayRef of objects or hash references, so instead we want to coerce
from an arrayref of a union type - which we can make using the | operator:

used actually construct a new type constraint object rather than a
frobnicator, which is at best surprising, and at worst downright enraging.

Fortunately, this is now fixed - if your type is a class type, or a subtype
of a class type, MooseX::Types::TypeDecorator goes and finds the class and
checks ->can on it first - and if there's a method of that name, uses that
(and if there isn't, falls back to the type constraint object so generally
stuff that treats it as one of those doesn't notice the difference).

Typing is hard - let's go moosing

So, given all of the above, so far as I'm concerned there's now absolutely
no excuse not to use type libraries and namespaced types - it's less typing,
less hassle, avoids clashes, and better still if you mistype a type name
then perl gets to scream at your right then and there, which it sadly
can't do when you typo something in a string.

So, in summary: Moose rocks. So does MooseX::Types. Go forth and use them,
and be happy.