I am very pleased with
Params::Validate. Why?
Goodbye ||=, Goodbye ref $x eq 'ARRAY'
I'm sure we've all seen subroutines like this:
sub greet {
my ($name, $age) = @_;
# required param
$name or die "must supply name" ;
# optional param, defaults to 25
$age ||= 25;
print "Hello, there $name. How does it feel to be $age?\n";
}
Well, try this out for size:
use Params::Validate qw(:all);
sub greet {
my %p = validate(@_, {
name => 1, # required
age => { default => 25 }
})
}
print "Hello, there $name. How does it feel to be $age?\n";
Personally I like the Params::Validate solution. No, let me take that
back... I
LOVE the Params::Validate solution. It is
much more definitional. This may not seem like a big win with
just two parameters but when you get 8 parameters, such as in
the table2() function that I recently wrote, it really begins to pay off.
You have one part of your code that serves as a "firewall" making sure
that everything the function requires is there and of the right
type. And any optional things get their default values. It is a huge
headache saver.
Hello infinitely extensible subroutines
With standard Perl subroutines, the calling order is significant and
things
get icky if you want to tack on a mandatory parameter later: you
either rewrite all the code and put this new mandatory parm before the
optional ones or write a new function.
Not so with PV. You just validate on one more parameter and specify
that
it is mandatory.
Named arguments
Named arguents are somewhat self-documenting in the calling
code. Not only that, but they shuttle quite nice to and fro,
hashes being the lingua franca between many external input and
output sources.
With
Params::Validate, you typically operate in named
parameter mode. I've never used it's positional verification.
Also, the two largest distributions using PV (Mason and Alzabo)
both use named parameters as well. But, if you want to go the
positional route, PV is right there with you.
Hello easy and confident documentation of function input
It is nice when one line of the data validation maps to one
English sentence. It makes it much easier to document
functions. For example, here is a sub that I added to
HTML::Element::Library today:
sub HTML::Element::iter2 {
my $tree = shift;
my %p = validate(
@_, {
# the container look-down. defaults to ['_tag' => 'dl']
wrapper_ld => { default => ['_tag' => 'dl'] },
# the data to fill the container with. mandatory
wrapper_data => 1,
# the routine to preprocess the HTML::Element container
# by default no preprocessing is done
wrapper_proc => { default => undef },
# the routine to find the "templated" sub-elements of container
# by default returns an arrayref consisting on the dt and dd tag
+s
item_ld => { default => sub {
my $tree = shift;
[
$tree->look_down('_tag' => 'dt'),
$tree->look_down('_tag' => 'dd')
];
}
},
# the routine to return a row of data from wrapper_data
# the default routine simply shifts off a row. you might
# replace this with $wrapper_data->next in some cases
item_data => { default => sub { my ($wrapper_data) = @_;
shift(@{$wrapper_data}) ;
}},
# the routine to take the row of data and populate the item tags
# the default routine takes a two-element array and fills the
# dt and dd tags
item_proc => {
default => sub {
my ($item_elems, $item_data, $row_count) = @_;
$item_elems->[$_]->replace_content($item_data->[$_]) for (0,1) ;
$item_elems;
}},
# the routine to place the accumulated item rows back in the the
# HTML::Tree. By default removes the two sample rows (dt and dd)
# and replaces them with all the item rows
splice => { default => sub {
my ($container, @item_elems) = @_;
$container->splice_content(0, 2, @item_elems);
}
},
# output debug info? by default, no
debug => {default => 0}
Summary
See Also
Params::Validate review by
rinceWind
