Better Perl: More on signatures and types
Tags: programming, perl
Published: 2021-02-16 23:24:24

---
title: Better Perl: More on signatures and types
published: true
date: 2021-02-16 23:19:02 UTC
tags: Programming,Perl
canonical_url: https://phoenixtrap.com/2021/02/16/better-perl-more-on-signatures-and-types/
---

A few weeks ago I wrote an article covering [six ways to do subroutine signatures and type constraints in Perl](https://phoenixtrap.com/index.php/2021/01/27/better-perl-with-subroutine-signatures-and-type-validation/). Some of the feedback I got indicated that there were more options to consider, so for the [presentation I gave at Houston Perl Mongers](https://phoenixtrap.com/index.php/2021/02/11/slides-from-tonights-houston-perl-mongers-presentation/) I quickly summarized at the end seven more modules from CPAN that offer these features. Still more feedback showed that I had missed five more modules, so at the risk of becoming “the signatures guy” here they are.

## [Class::ParamParser](https://metacpan.org/pod/Class::ParamParser) (updated)

First released in 2000 as part of a larger project, this may be the first general-purpose parameter parser to appear on CPAN. Although the documentation examples use it as a parent class, you should follow the suggestion further down and use its two methods `params_to_hash` and `params_to_array` directly from the class. Both take the same list of arguments, and only differ on whether they return a hash reference containing named parameters or an array reference containing positional parameters.

There are options for slurping extra passed values into another hash bucket and lowercasing named parameters, and it will automatically chop off any leading hyphens in your parameter names. You can also alias multiple named parameters to the same resulting argument. The module doesn't provide any facility for type validation, though.

## [Method::ParamValidator](https://metacpan.org/pod/Method::ParamValidator)

This adds the interesting wrinkle of being configurable with an external JSON file; otherwise, it seems you have to call various methods on a validator object to add parameters (which it calls _fields_) or methods to validate. It doesn’t seem to support slurping extra values nor positional parameters, but its type validation lets you use arbitrary code references. The documentation could use a bit of work with more examples of real-world usage rather than test script extracts. The author says it’s “just a prototype,” though.

## [Mojolicious::Validator](https://metacpan.org/pod/Mojolicious::Validator)

The [Mojolicious real-time web framework](https://mojolicious.org/) has a built-in validator, but it’s geared towards [validating HTTP parameters](https://docs.mojolicious.org/Mojolicious/Guides/Rendering#Form-validation) rather than subroutine arguments. There’s also a [MojoX::Validator](https://metacpan.org/pod/MojoX::Validator) wrapper for [Input::Validator](https://metacpan.org/pod/Input::Validator) that performs much the same task. You could press either into service as subroutine validators if you’re already using Mojolicious, but they aren’t structured that way.

## [Return::Type](https://metacpan.org/pod/Return::Type)

This isn’t for input parameters to subroutines; rather, it provides an attribute that specifies what type your subroutines **return**. As such, it’s complimentary to most of the other techniques covered in this series. It works with [Type::Tiny](https://metacpan.org/pod/Type::Tiny), [MooseX::Types](https://metacpan.org/pod/MooseX::Types), or [MouseX::Types](https://metacpan.org/pod/MouseX::Types), and because Perl functions can tell whether they’re in scalar or list context, you can specify different type constraints for each.

There are several other modules with similar functionality, but these are outside the scope of this article.

## [routines](https://metacpan.org/pod/routines)

Based on [Function::Parameters](https://metacpan.org/pod/Function::Parameters) (covered [previously](https://phoenixtrap.com/index.php/2021/01/27/better-perl-with-subroutine-signatures-and-type-validation/)), this pragma adds support for a [registry](https://metacpan.org/pod/registry) for storing [Type::Tiny](https://metacpan.org/pod/Type::Tiny) type libraries. It doesn’t appear to offer any other signature features, though. Feel free to correct me in the comments.

As I said in [my slide deck](https://phoenixtrap.com/index.php/2021/02/11/slides-from-tonights-houston-perl-mongers-presentation/), maybe we’re taking [TMTOWTDI](https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it) too far? It’s nice to be spoiled for options, though. I still recommend [Type::Tiny](https://metacpan.org/pod/Type::Tiny)’s [Type::Params](https://metacpan.org/pod/Type::Params) for its performance and flexibility, or [Params::ValidationCompiler](https://metacpan.org/pod/Params::ValidationCompiler) if you’re using type libraries from [Specio](https://metacpan.org/pod/Specio) or [Moose](https://metacpan.org/pod/Moose). Some useful side-by-side benchmarks would be nice; maybe I’ll save that for another article and further risk being labeled “the signatures guy.”