Skip navigation

The problem with Modern::Perl.

Modern::Perl has laudable goals. I agree with chromatic. This is why I use 5.10.0 at work. This is why I will be upgrading to 5.10.1 almost as soon as it is released. I even plan on testing our code with the 5.10.1 release candidates. The first significant line in all our modules is “use 5.010;“. (The second is “use utf8;“.) As I said in a prior post, I upgrade all the modules that we use from the CPAN every three months.

However, as a practical matter, Modern::Perl is broken. What happens when perl 5.12 comes out? Does chromatic upgrade the module to add “use feature qw/ :5.12 /;“? Are all of the modules that use Modern::Perl suddenly broken? Someone requested that TestingAndDebugging::RequireUseStrict include Modern::Perl in the default set of modules that are treated as equivalent to “use strict;“. (You can add to that list yourself via the “equivalent_modules” option.) I don’t want to do that; I want to discourage the use of Modern::Perl. Maybe if there was a Modern::Perl_5_10 I’d think differently.

pmtools

pmtools is a set of little utilities for dealing with your installed modules. (Unfortunately, if you want to install these using CPAN.pm or CPANPLUS, you need to tell them to install “Devel::Loaded”.)

The ones that I use on a daily basis are pmpath, pmvers, and pminst.

I use pminst and pmvers to maintain a couple of DarkPANs, a.k.a. internal CPANs. I want to manage the versions of modules we use so that we don’t get surprises, like they won’t compile in our environment or they make changes that we can’t deal with right away. So, we have repositories in the standard CPAN layout and point CPAN(PLUS)? to those instead of the public CPAN.

Since the install tools are pointed at an internal repository, when I want to use a module that we haven’t used before, I need to download the distribution myself. It’s not as simple as just grabbing the distribution archive. I need to get the module’s dependencencies. In order to find out which of those I’ve already gets installed, I use pminst.

If I run into a problem with a module, I need to figure out which version I’ve got in order to look at whether there’s an updated version or to properly report a bug. Thus, pmvers.

I regularly need to figure out what path I’m getting a module from, for example whether it’s in the core perl install or in my installed modules path. (In order to avoid cross-project module version entanglements, we don’t use sitelibs; we use separate install directories. The core perl installation is readonly and nothing ever gets added to it.) pmpath probably gets the most usage of the three.

The most common of my use of pmpath isn’t actually direct. When I get an exception in some module, I want to bring it up in the editor to see the code. I’ve created a script that I call pmedit:

 1 #!/usr/bin/env bash
 2
 3 if [[ $# -le 0 ]]
 4 then
 5     echo "usage: $0 module […]" >&2
 6     exit 1
 7 fi
 8
 9 declare -a FILES
10
11 for MODULE in "$@"
12 do
13     FILE=`pmpath "${MODULE}" 2>/dev/null`
14     if [[ -z "${FILE}" ]]
15     then
16         echo "Could not find ${MODULE}." >&2
17     else
18         FILES[${#FILES[@]}]="${FILE}"
19     fi
20 done
21
22 if [[ ${#FILES[@]} -gt 0 ]]
23 then
24     gvim "${FILES[@]}"
25 fi

Eliminating all inheritance from my code.

Moose Roles rock! I’m following Ovid‘s example and getting rid of inheritance in my code: nothing will inherit from anything. You’ll be able to tell what the code does without searching for a superclass’ superclass’ superclass.

It really feels weird downloading your own code from a public website.

Downloading the Perl::Critic from work which I uploaded at home this morning. It’s a different feeling than downloading from private ‘net storage; it’s just a transfer mechanism in that case. But using the CPAN to get your own open-source code is just… interesting feeling.

Someone’s built a GUI on top of my code!

I added the metadata functionality to Perl::Critic that allows this sort of thing a while back and now some one is finally using it. Woohoo!

I’m quite chuffed.

Modern Perl

Communicating opinions via method implementation choices in class hierarchies.

Dealing with the differences in the ways that the CME and the ICE use FIX has been interesting. Some of the differences are simply, oh, this one does things this way and this other one does things another. And some of them are, this is what I expect should be normal and why the hell is this exchange doing things like this? This ends up being reflected in the code.

I’ve got a base message class with a subclass for each exchange. For the former kind of differences, I’ve got an abstract method on the base class with the appropriate implementations on the subclasses. For the “WTF?” things, I’ve got a default implementation on the base class, and override that on the specific subclass.

What kind of personality does Perl::Critic have?

Probably pedantic, but we’ll see what it says.

The most significant Perl::Critic release in a long while.

Perl::Critic 1.094 is on its way to a CPAN mirror near you. There are a number of changes in it, but there’s one in particular that I want to point out. A new policy called Miscellanea::ProhibitUselessNoCritic.

Adam Kennedy wrote a journal entry where he mentioned “the expense of having to maintain [## no critic] entries permanently”. This inspired the creation of the new policy.

One of the problems with Perl::Critic is that you may, over time, end up with policy disabling comments scattered across your code that no longer apply, making the code harder to understand. This policy will complain about any ## no critic that doesn’t actually disable any policies. You then know that you can remove those comments, making your code cleaner and congratulating yourself for solving whatever issue that caused you to put it there in the first place.

This post originally appeared at use.perl.org.

Improbable vs Statistically Impossible

Schwern on git hashes.

Every time this comes up someone says “but what if they collide?! Hashes sometimes collide!”

I confess to being one of those who want things to be really impossible, not merely “statistically impossible”.