Narrowly destricted refs

*{; no strict 'refs'; \*{ "${pkg}::type" } } = sub () { $type };
push @{; no strict 'refs'; \@{ "${pkg}::ISA" } }, __PACKAGE__;
# ... and so on

I really don’t feel like I have anything to add but I suppose it may not be obvious that the point of this exercise is to surgically limit the lifting of the refs stricture to just the desired symbolic dereference (without leaking it even as far as any other part of the expression) – in the most compact form possible.

I also suppose I ought to expand on it by way of explanation for the less travelled in the dustier corners of Perl 5 syntax:

Modern functions in a post-modern language

The new _modern function variants in Time::Local have come up a few times lately. I have some thoughts on them, but presenting my position dispassionately enough to be persuasive demands an essay of unfortunate length… so let’s get on with it.

Let me lead with the positive: it is a problem with the traditional functions that they would sometimes add 1900 to the year and sometimes a different value and sometimes nothing. This heuristic in the interface is bad. Doing something about it is a good idea.

Let me also lay out some simple statements of fact: Perl ships with gmtime and localtime functions which return a datetime represented as a list of numbers. Time::Local supplies inverse functions which take such a list and return the Unix epoch time that corresponds to that datetime. The Perl functions, among other things, return the year as the number of years since 1900. A correct inverse of the core functions would therefore simply add 1900 to the year passed.

The traditional Time::Local functions do not fully do this: they only do it if the year number is just big enough but not too big.

Modern Perl CGI

The contemporarily unique strengths of CGI as a deployment strategy are that CGI scripts ⓐ can just be dumped in the filesystem to deploy them and ⓑ do not have any of the issues of long-running processes: they tie up no resources when not in use and are extremely reliable because of the execution model, in which global state always starts from a blank slate when serving a request and there is no process that outlives the request and could wedge itself. Anyone who consciously chooses CGI over alternative deployment strategies nowadays probably has a fire-and-forget use case where the script will be seeing too little traffic to be worth any effort to tend to it regularly.

In his article about modern CGI, Grinnz suggested using Mojolicious rather than as a framework for writing CGI scripts. Mojolicious is explicitly intended for users who are willing to keep changing their own application code in order to enjoy a framework whose API design can be changed (hopefully for the better) without sacrificing the framework’s code quality. In the Venn diagram of the CGI-for-deployment and Mojolicious-for-framework audiences, there is no overlap. So I consider Mojolicious an oxymoronic alternative to

A much better alternative to is simply raw Plack. It is lower-level than Mojolicious, so the code will be more verbose, but Plack’s stance on compatibility matches a fire-and-forget use case far better. CGI::Alternatives does not do a great job of selling that option, so let’s just see what it would look like in practice for the given example.


I just shipped 1.300 of this module to the CPAN and it occurs to me that I’ve never talked about it here. I suppose I figured that what it does is so simple that there’s not much to say about it. But it‘s useful if you need what it does, and I wrote it because nobody else had.

  1. Do you have a web site being served over HTTPS?
  2. Do you want to redirect visitors coming in over HTTP to HTTPS?
    (I.e. send visitors of to instead.)

If you answered yes once, you almost certainly answered yes twice. Right? It’s such a common thing to need.

But when I went looking for a way to make my PSGI application do that, I found nothing on CPAN.


Last year I released this new module.

I want to talk about its purpose briefly, because in the time since, people have published benchmarks of how it performs compared to other modules that offer alternatives to eval. The latest example of such a benchmark is part of the Exceptions chapter in Minimum Viable Perl (via), but they go as far back as Diab Jerius’ shootout right after I released the module.

It is, of course, interesting to see the figures to see where Try::Tiny::Tiny falls.

However, simply treating it like another contender in such a contest misunderstands its purpose. Try::Tiny::Tiny is not meant to compete with any of the other modules. It is not meant to be your choice for exception block syntax.

I do not recommend that you use Try::Tiny::Tiny in your own code.