Take me over?
NAME
MooseX::Params::Validate - an extension of Params::Validate for using Moose's types
SYNOPSIS
package Foo;
use Moose;
use MooseX::Params::Validate;
sub foo {
my ($self, %params) = validate(\@_,
bar => { isa => 'Str', default => 'Moose' },
);
return "Horray for $params{bar}!";
}
sub bar {
my $self = shift;
my ($foo, $baz, $gorch) = validatep(\@_,
foo => { isa => 'Foo' },
baz => { isa => 'ArrayRef | HashRef', optional => 1 }
gorch => { isa => 'ArrayRef[Int]', optional => 1 }
);
[ $foo, $baz, $gorch ];
}
DESCRIPTION
This module fills a gap in Moose by adding method parameter validation to Moose. This is just one of many developing options, it should not be considered the "official" one by any means though.
This is an early release of this module, and many things will likely change and get added, so watch out :)
CAVEATS
It is not possible to introspect the method parameter specs, they are created as needed when the method is called and cached for subsequent calls.
EXPORTS
- validate (\@_, %parameter_spec)
-
This behaves similar to the standard Params::Validate
validate
function and returns the captured values in a HASH. The one exception being that if it spots an instance in the@_
, then it will handle it appropriately (unlike Params::Validate which forces you to shift you$self
first).The
%parameter_spec
accepts the following options:- isa
-
The
isa
option can be either; class name, Moose type constraint name or an anon Moose type constraint. - does
-
The
does
option can be either; role name or an anon Moose type constraint. - default
-
This is the default value to be used if the value is not supplied.
- optional
-
As with Params::Validate, all options are considered required unless otherwise specified. This option is passed directly to Params::Validate.
- coerce
-
If this is true and the parameter has a type constraint which has coercions, then the coercion will be called for this parameter. If the type does have coercions, then this parameter is ignored.
The plan is to support more options in the future as well.
- validatep (\@_, %parameter_spec)
-
The
%parameter_spec
accepts the same options as above, but returns the parameters as positional values instead of a HASH. This is best explained by example:sub foo { my ($self, $foo, $bar) = validatep(\@_, foo => { isa => 'Foo' }, bar => { isa => 'Bar' }, ); $foo->baz($bar); }
We capture the order in which you defined the parameters and then return them as positionals in the same order. If a param is marked optional and not included, then it will be set to
undef
.
IMPORTANT NOTE ON CACHING
When validate
or validatep
are called the first time, the parameter spec is prepared and cached to avoid unnecessary regeneration. It uses the fully qualified name of the subroutine (package + subname) as the cache key. In 99.999% of the use cases for this module, that will be the right thing to do.
However, I have (ab)used this module occasionally to handle dynamic sets of parameters. In this special use case you can do a couple things to better control the caching behavior.
Passing in the
MX_PARAMS_VALIDATE_NO_CACHE
flag in the parameter spec this will prevent the parameter spec from being cached. To see an example of this, take a look at t/003_nocache_flag.t.Passing in
MX_PARAMS_VALIDATE_CACHE_KEY
with a value to be used as the cache key will bypass the normal cache key generation. To see an example of this, take a look at t/004_custom_cache_key.t.
METHODS
- import
Introspection
- meta
BUGS
All complex software has bugs lurking in it, and this module is no exception. If you find a bug please either email me, or add the bug to cpan-RT.
AUTHOR
Stevan Little <stevan.little@iinteractive.com>
COPYRIGHT AND LICENSE
Copyright 2007-2008 by Infinity Interactive, Inc.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.