circus theme party

Last week’s arti­cle got a great response on Hacker News, and this par­tic­u­lar com­ment caught my eye:

I think this is the real point about Perl code read­abil­i­ty: it gives you enough flex­i­bil­i­ty to do things how­ev­er you like, and as a result many pro­gram­mers are faced with a mir­ror that reflects their own bad prac­tices back at them.

orev, Hacker News

This is why Damian Conway’s Perl Best Practices (2005) is one of my favorite books and perlcritic, the code ana­lyz­er is one of my favorite tools. (Though the for­mer could do with an update and the lat­ter includes poli­cies that con­tra­dict Conway.) Point perlcritic at your code, maybe add some oth­er poli­cies that agree with your house style, and grad­u­al­ly ratch­et up the sever­i­ty lev­el from gen­tle” to bru­tal.” All kinds of bad juju will come to light, from waste­ful­ly using grep to hav­ing too many sub­rou­tine argu­ments to catch­ing pri­vate vari­able use from oth­er pack­ages. perlcritic offers a use­ful base­line of con­duct and you can always cus­tomize its con­fig­u­ra­tion to your own tastes.

The oth­er con­for­mance tool in a Perl devel­op­er’s belt is perltidy, and it too has a Conway-​compatible con­fig­u­ra­tion as well as its default Perl Style Guide set­tings. I’ve found that more than any­thing else, perltidy helps set­tle argu­ments both between devel­op­ers and between their code in help­ing to avoid exces­sive merge conflicts.

But apart from extra tools, Perl the lan­guage itself can be bent and even bro­ken to suit just about any­one’s agen­da. Those used to more bondage-​and-​discipline lan­guages (hi, Java!) might feel revul­sion at the lengths to which this has some­times been tak­en, but per the quote above this is less an indict­ment of the lan­guage and more of its less method­i­cal pro­gram­mers.

Some of this behav­ior can be reha­bil­i­tat­ed with perlcritic and perltidy, but what about oth­er sins attrib­uted to Perl? Here are a few peren­ni­al favorites”:

Objects and Object-​Oriented Programming

Perl has a min­i­mal­ist object sys­tem based on earlier-​available lan­guage con­cepts like data struc­tures (often hash­es, which it has in com­mon with JavaScript), pack­ages, and sub­rou­tines. Since Perl 5’s release in 1994 much ver­bose OO code has been writ­ten using these tools.

The good news is that since 2007 we’ve had a sophis­ti­cat­ed metaobject-​protocol-​based lay­er on top of them called Moose, since 2010 a light­weight but forward-​compatible sys­tem called Moo, and a cou­ple of even tinier options as described in the Perl OO Tutorial. Waiting in the wings is Corinna, an effort to bring next-​generation object capa­bil­i­ties into the Perl core itself, and Object::Pad, a test­bed for some of the ideas in Corinna that you can use today in cur­rent code. (Really, please try it—the author needs feed­back!)

All this is to say that 99% of the time you nev­er need trou­ble your­self with bless, con­struc­tors, or writ­ing acces­sors for class or object attrib­ut­es. Smarter peo­ple than me have done the work for you, and you might even find a con­cept or three that you wish oth­er lan­guages had.


There are two major ones: list and scalar. Another way to think of it is plur­al” vs. sin­gu­lar” in English, which is hope­ful­ly a thing you’re famil­iar with as you’re read­ing this blog.

Some func­tions in Perl act dif­fer­ent­ly depend­ing on whether the expect­ed return val­ue is a list or a scalar, and a func­tion will pro­vide a list or scalar con­text to its argu­ments. Mostly these act just as you would expect or would like them to, and you can find out how a func­tion behaves by read­ing its doc­u­men­ta­tion. Your own func­tions can behave like this too, but there’s usu­al­ly no need as both scalars and lists are auto­mat­i­cal­ly inter­pret­ed into lists.” Again, Perl’s DWIMmery at work.

Subroutine and Method Arguments

I’ve already writ­ten about this. Twice. And pre­sent­ed about it. Twice. The short ver­sion: Perl has sig­na­tures, but they’ve been con­sid­ered exper­i­men­tal for a while. In the mean­time, there are alter­na­tives on CPAN. You can even have type con­straints if you want.

I’ll leave you with this: Over the past month, Neil Bowers of the Perl Steering Council has been col­lect­ing quirks like these from Perl devel­op­ers. The PSC is review­ing this col­lec­tion for poten­tial doc­u­men­ta­tion fix­es, bug fix­es, fur­ther dis­cus­sion, etc. I would­n’t expect to see any fun­da­men­tal changes to the lan­guage out of this effort, but it’s a good sign that poten­tial­ly con­fus­ing fea­tures are being addressed. 

I’ll be repris­ing my pre­sen­ta­tion on Perl sub­rou­tine sig­na­tures and type val­i­da­tion for the Boston Perl Mongers on Tuesday, March 9 at 7 PM EST. Visit their wiki for details; they’ll be post­ing the Jitsi URL short­ly before the meet­ing. There’s also a Meetup page.

A few weeks ago I wrote an arti­cle cov­er­ing six ways to do sub­rou­tine sig­na­tures and type con­straints in Perl. Some of the feed­back I got indi­cat­ed that there were more options to con­sid­er, so for the pre­sen­ta­tion I gave at Houston Perl Mongers I quick­ly sum­ma­rized at the end sev­en more mod­ules from CPAN that offer these fea­tures. Still more feed­back showed that I had missed five more mod­ules, so at the risk of becom­ing the sig­na­tures guy” here they are.

Class::ParamParser (updated)

First released in 2000 as part of a larg­er project, this may be the first general-​purpose para­me­ter pars­er to appear on CPAN. Although the doc­u­men­ta­tion exam­ples use it as a par­ent class, you should fol­low the sug­ges­tion fur­ther down and use its two meth­ods params_to_hash and params_to_array direct­ly from the class. Both take the same list of argu­ments, and only dif­fer on whether they return a hash ref­er­ence con­tain­ing named para­me­ters or an array ref­er­ence con­tain­ing posi­tion­al parameters.

There are options for slurp­ing extra passed val­ues into anoth­er hash buck­et and low­er­cas­ing named para­me­ters, and it will auto­mat­i­cal­ly chop off any lead­ing hyphens in your para­me­ter names. You can also alias mul­ti­ple named para­me­ters to the same result­ing argu­ment. The mod­ule does­n’t pro­vide any facil­i­ty for type val­i­da­tion, though.


This adds the inter­est­ing wrin­kle of being con­fig­urable with an exter­nal JSON file; oth­er­wise, it seems you have to call var­i­ous meth­ods on a val­ida­tor object to add para­me­ters (which it calls fields) or meth­ods to val­i­date. It does­n’t seem to sup­port slurp­ing extra val­ues nor posi­tion­al para­me­ters, but its type val­i­da­tion lets you use arbi­trary code ref­er­ences. The doc­u­men­ta­tion could use a bit of work with more exam­ples of real-​world usage rather than test script extracts. The author says it’s just a pro­to­type,” though.


The Mojolicious real-​time web frame­work has a built-​in val­ida­tor, but it’s geared towards val­i­dat­ing HTTP para­me­ters rather than sub­rou­tine argu­ments. There’s also a MojoX::Validator wrap­per for Input::Validator that per­forms much the same task. You could press either into ser­vice as sub­rou­tine val­ida­tors if you’re already using Mojolicious, but they aren’t struc­tured that way.


This isn’t for input para­me­ters to sub­rou­tines; rather, it pro­vides an attribute that spec­i­fies what type your sub­rou­tines return. As such, it’s com­pli­men­ta­ry to most of the oth­er tech­niques cov­ered in this series. It works with Type::Tiny, MooseX::Types, or MouseX::Types, and because Perl func­tions can tell whether they’re in scalar or list con­text, you can spec­i­fy dif­fer­ent type con­straints for each.

There are sev­er­al oth­er mod­ules with sim­i­lar func­tion­al­i­ty, but these are out­side the scope of this article.


Based on Function::Parameters (cov­ered pre­vi­ous­ly), this prag­ma adds sup­port for a reg­istry for stor­ing Type::Tiny type libraries. It does­n’t appear to offer any oth­er sig­na­ture fea­tures, though. Feel free to cor­rect me in the comments.

As I said in my slide deck, maybe we’re tak­ing TMTOWTDI too far? It’s nice to be spoiled for options, though. I still rec­om­mend Type::Tinys Type::Params for its per­for­mance and flex­i­bil­i­ty, or Params::ValidationCompiler if you’re using type libraries from Specio or Moose. Some use­ful side-​by-​side bench­marks would be nice; maybe I’ll save that for anoth­er arti­cle and fur­ther risk being labeled the sig­na­tures guy.”