The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

Type::Tiny::Manual - an overview of Type::Tiny

SYNOPSIS

Type::Tiny is a small framework for writing type constraints and organizing them into type libraries. Although inspired by Moose's type constraint API, it has no non-core dependencies, and can be used with Moose, Mouse and Moo.

It provides a small Moose-inspired library of built-in type constraints.

SEE ALSO

  • Libraries - how to build a type library with Type::Tiny, Type::Library and Type::Utils

  • Using with Moose - how to use Type::Tiny and Type::Library with Moose

  • Using with Mouse - how to use Type::Tiny and Type::Library with Mouse

  • Using with Moo - how to use Type::Tiny and Type::Library with Moo

  • Type::Tiny and friends don't need to be used within an OO framework. See FreeMind::Node for an example that does not.

TYPE::TINY VERSUS X

Specio

Type::Tiny is similar in aim to Specio. The major differences are that Type::Tiny is "tiny"; and Type::Tiny dispenses with the idea of a type registry and stringy access to type constraints.

MooseX::Types

Type::Tiny libraries expose a similar interface to MooseX::Types libraries. In most cases you should be able to rewrite a MooseX::Types library to use Type::Tiny pretty easily.

MooX::Types::MooseLike

Type::Tiny is faster and supports coercions.

BUGS

Please report any bugs to http://rt.cpan.org/Dist/Display.html?Queue=Type-Tiny.

SUPPORT

IRC: support is available through in the #moose channel on irc.perl.org. If Type::Tiny discussion there becomes overwhelming (unlikely) then I'll move it to a separate channel.

CAVEATS

Mutability of Type::Coercion

Type::Tiny type constraints are designed as immutable objects. Once you've created a constraint, rather than modifying it you generally create child constraints to do what you need.

Type::Coercion objects, on the other hand, are mutable. Coercion routines can be added at any time during the object's lifetime.

This combination of features means that if you create a Type::Tiny type constraint, then create a Moose or Mouse type from it (the moose_type and mouse_type lazily built attributes), and then add coercions to the Type::Tiny constraint, the Moose/Mouse constraint will not see them.

In general you should avoid adding coercions to a type constraint once the type constraint has started being used. Add coercions straight after defining the type. The plus_coercions method (which returns a new type constraint with extra coercions, so doesn't violate immutability) is a better technique than adding coercions willy-nilly during the course of a constraint's lifetime.

I do consider this to be an issue that needs resolving in a future release. The likely solution will be to have the ability to "freeze" a Type::Coercion object, and then change the moose_type and mouse_type lazy builders to make them automatically freeze the type's associated coercion.

AUTHOR

Toby Inkster <tobyink@cpan.org>.

COPYRIGHT AND LICENCE

This software is copyright (c) 2013 by Toby Inkster.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

DISCLAIMER OF WARRANTIES

THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.