The majority of the size of the distribution is the test suite. With nearly 1200 CPAN modules depending on Type::Tiny directly or indirectly, having a comprehensive test suite seems a good idea. Documentation and examples make up most of the remaining size.
In terms of dependancies, the module Type::Tiny itself has no non-core dependancies (apart from a few modules that are bundled with it).
$ perl -Ilib -MType::Tiny -E'say for sort keys %INC'
Eval/TypeTiny.pm
Exporter.pm
List/Util.pm
Scalar/Util.pm
Type/Tiny.pm
Type/Tiny/XS.pm
Types/TypeTiny.pm
XSLoader.pm
feature.pm
overload.pm
overloading.pm
strict.pm
warnings.pm
warnings/register.pm
As you can see, they're all in core, except:
- Eval::TypeTiny not in core, but bundled with Type::Tiny
- Type::Tiny::XS loaded via eval { require Type::Tiny::XS } so it's an optional dependancy
- Types::TypeTiny not in core, but bundled with Type::Tiny
The module I recommended, Types::Common::Numeric does have one additional non-core dependancy: Exporter::Tiny.
Exporter::Tiny was originally called Exporter::TypeTiny and bundled as part of the distribution too. However, I was convinced by chocolateboy that it had merit as a standalone module, so I split it out as a separate CPAN distribution. Seems he was right as it now has nearly 4000 downstream dependants. I don't think the fact that some of the modules bundled with Type::Tiny (but not Type::Tiny itself) require Exporter::Tiny makes it unworthy of the "tiny" name.
Yes, if it's just one range check in a script, requiring any module whatsoever seems like overkill. But realistically, problems like this don't come up in isolation. Most non-trivial programs will need to sanity-check data in loads of places checking the data passed to object constructors, checking function and method arguments, etc. Type::Tiny and its bundled modules provide a framework for this which is more concise and usually more correct and faster than handwritten code.
As an example of correctness, spot the problem with this code:
use strict;
use warnings FATAL => qw(all);
sub set_age {
my $self = shift;
my ($age) = @_;
croak "age cannot be negative" unless $age >= 0;
$self->{age} = $age;
return $self;
}
Okay, so the obvious thing is we're not checking $age is a number. But if we do $object->set_age("old") we'll get a warning about doing a numeric comparison on a string, so we're covered, right?
Wrong. $object->set_age([]) will be allowed. Numeric operations on references silently act on their reference address without triggering any warnings.
Rewriting it to this:
use feature "state";
use strict;
use warnings FATAL => qw(all);
use Type::Params qw(compile);
use Types::Standard qw(Object);
use Types::Common::Numeric qw(PositiveOrZeroInt);
sub set_age {
state $check = compile(Object, PositiveOrZeroInt);
my ($self, $age) = $check->(@_);
$self->{age} = $age;
return $self;
}
And as a bonus, it will test that $self is an object, and will check that @_==2.
None of the other answers to the OP's question even bothered checking $x was actually a number. IntRange will check that it's defined, it's a non-reference, and it's an integer before checking that it's in the right range.
|