=pod

=encoding utf-8

=head1 NAME

Type::Tiny::Manual::UsingWithMoose - how to use Type::Tiny and Type::Library with Moose

=head1 SYNOPSIS

   {
      package Person;
      
      use Moose;
      use Types::Standard qw( Str Int );
      
      has name => (
         is      => "ro",
         isa     => Str,
      );
      
      my $PositiveInt = Int
         -> where( sub { $_ > 0 } )
         -> plus_coercions( Int, sub { abs $_ } );
      
      has age => (
         is      => "ro",
         isa     => $PositiveInt,
         coerce  => 1,
         writer  => "_set_age",
      );
      
      sub get_older {
         my $self = shift;
         my ($years) = @_;
         $PositiveInt->assert_valid($years);
         $self->_set_age($self->age + $years);
      }
   }

=head1 DESCRIPTION

Type::Tiny is tested with L<Moose> 2.0007 and above.

L<Type::Tiny> type constraints have an API almost identical to that of
L<Moose::Meta::TypeConstraint>. It is also able to build a
Moose::Meta::TypeConstraint constraint from a Type::Tiny constraint, and
will do so automatically when needed. When Moose.pm is loaded, Type::Tiny
will use Perl's C<AUTOLOAD> feature to proxy method calls through to the
Moose::Meta::TypeConstraint object. In short, you can use a Type::Tiny
object pretty much anywhere you'd use a Moose::Meta::TypeConstraint and
you are unlikely to notice the difference.

=head2 Per-Attribute Coercions

Type::Tiny offers convenience methods to alter the list of coercions
associated with a type constraint. Let's imagine we wish to allow our
C<name> attribute to be coerced from an arrayref of strings.

      has name => (
         is      => "ro",
         isa     => Str->plus_coercions(
            ArrayRef[Str], sub { join " ", @{$_} },
         ),
         coerce  => 1,
      );

This coercion will apply to the C<name> attribute only; other attributes
using the C<Str> type constraint will be unaffected.

See the documentation for C<plus_coercions>, C<minus_coercions> and
C<no_coercions> in L<Type::Tiny>.

=head2 Optimization

The usual advice for optimizing type constraints applies: use type constraints
which can be inlined whenever possible.

Defining coercions as strings rather than coderefs won't give you as much of
a boost with Moose as it does with Moo, because Moose doesn't inline coercion
code. However, it should still improve performance somewhat because it allows
L<Type::Coercion> to do some internal inlining.

See also L<Type::Tiny::Manual::Optimization>.

=head2 Interactions with MooseX-Types

Type::Tiny and MooseX::Types type constraints should "play nice". If, for
example, C<ArrayRef> is taken from L<Types::Standard> (i.e. a Type::Tiny-based
type library), and C<PositiveInt> is taken from L<MooseX::Types::Common::Numeric>,
then the following should "just work":

   isa => ArrayRef[ PositiveInt ]

   isa => PositiveInt | ArrayRef

=head1 SEE ALSO

For examples using Type::Tiny with L<Moose> see the SYNOPSIS sections of
L<Type::Tiny> and L<Type::Library>, and the
L<Moose integration tests|https://github.com/tobyink/p5-type-tiny/tree/master/t/30-integration/Moose>,
and
L<MooseX-Types integration tests|https://github.com/tobyink/p5-type-tiny/tree/master/t/30-integration/MooseX-Types>
in the test suite.

=head1 AUTHOR

Toby Inkster E<lt>tobyink@cpan.orgE<gt>.

=head1 COPYRIGHT AND LICENCE

This software is copyright (c) 2013-2014, 2017-2019 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.

=head1 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.

=cut