O pumpking! My pumpking!

As many people know by now, Ricardo Signes recently announced that he will be standing down as pumpking once Perl 5.24.0 is released, after four and a half years in the role — not to mention an unprecedented five stable 5.x.0 releases of Perl!

Since the Perl QA Hackathon is the first Perl event Rik has attended since his announcement, we thought it would be fitting to offer Rik a token of our appreciation for the remarkable and tireless work he’s put in during his service. So we closed up the second day of the hackathon with a short presentation and a small expression of our gratitude (and hopefully one that Rik didn’t find too embarrassing!)

In particular, Rik has now joined the very select group of people who’ve received a Silver Camel.

P4220270.jpg

Perl QA Hackathon 2016: Configure

I write this from sunny Rugby, England, where I’m attending the QA Hackathon 2016. It’s always great to spend time with people who are active in the Perl community, not just socialising, but working on the software we all depend on.

Perl 5.17.8’s release epigraph

Cross-posted from my other blog.

Yesterday I had the pleasure of releasing version 5.17.8 of Perl. Perl has had regular, time-boxed monthly development releases for about three years now. This great improvement on the previous situation has been accomplished partly by making the release process into something that can be done even by people who, like me, are far from being experts in Perl’s internals.

One of Perl’s long-standing traditions is that release announcements are accompanied by an epigraph, chosen by the release victim volunteer. Here are some notes about the epigraph I picked for 5.17.8.

Monkey-patching, subclassing, and accidental overriding

One of the great things about open-source software is the ability to reuse handy classes written by other people. But sometimes, you find yourself using a class that doesn't have quite enough features for what you're trying to do. What's the best way to deal with that sort of situation?

One option would be to monkey-patch new code into the class you're using — just add extra subroutines to the original namespace. But unconstrained monkey-patching has consequences that make it extremely hard to use in practice. So the usual alternative recommendation is to subclass the upstream code, add the new methods in the subclass, and then ensure that the rest of your program always uses the subclass in place of the original. But that approach has two flaws. First, it can be awkward to make sure your subclass is always used in the right places. Second, it doesn't actually fix the problem: you can still experience all the same issues as with monkey-patching!

I gave a talk on this topic at this year's YAPC::EU in Rīga, and it's getting a repeat (and extended!) outing at the inaugural Dynamic Languages Conference today. But if you'd like to read the full details, the corresponding paper is now on my website.

Enjoy!