We need programmers who like to play on the bleading edge. By trying out new features, they are able to report on problems that they find – and, in doing so, improve the experience for the many people who follow them.

I’m not usually much of a bleading edge programmer. But I’ve been enjoying Perl’s new object-oriented programming features, so I’ve been using them a lot. And, in the process, I’ve found a few issues that I’ve reported (or, in a couple of cases, will report) to the relevant people.

Often, the problem that the bleading edgers come across are problems with the feature itself. That’s not the case with me. I’ve been finding problems with how Perl’s infrastructure deals with the new feature.

And please note, it would be easy to interpret this blog post as me complaining about these tools being “broken” because they aren’t keeping up with the development of the language. That’s not the case at all. I realise that these infrastructure projects are all run by volunteers and I’m grateful for all these people do – working for free, keeping these systems (systems that we often tend to take for granted) running. In cases where I think I would be at all useful I have, of course, offered my helping in implementing these fixes.

So what are the problems?

The first CPAN module I wrote that used the new class syntax was Amazon::Sites. As soon as I uploaded it, I knew something was awry. I got an email from the PAUSE indexer saying that it couldn’t understand my distribution tarball. I wasn’t sure what the problem was, but within an hour I got a follow-up email from Neil Bowers pointing out that PAUSE couldn’t find a package statement in my module. That’s not surprising, as the new class syntax uses class as a replacement for package. And PAUSE hadn’t been updated to recognise that syntax. Before emailing me, Neil had taken the time to raise an issue in the PAUSE repo and he suggested that the upcoming Perl Toolchain Summit would be a good opportunity to fix the problem. He also suggested that added a (strictly speaking, spurious) package line to the code would be a good workaround. I did that and uploaded a new version – which worked fine. And PAUSE was updated at the PTS. In the intervening time, I released a couple more modules that used the new syntax – so they also have the extra package line.

The next problem is one that probably only affects me. Back in January, I wrote about some reusable GitHub Actions that I had developed for Perl code. Although it’s not mentioned in the blog post, I had added an action that uses Perl::Metrics::Simple to report on the complexity of my Perl code. I noticed that it was showing strange results for my modules that used the new syntax. Specifically, it wasn’t correctly reporting the complexity of code in methods. The reason is obvious, when you think about it. It’s just that Perl::Metrics::Simple doesn’t recognise the method keyword that is used in place of sub in the new OO syntax. I raised an issue in the repo for the module – optimistically promising a pull request in a few days. That didn’t happen as the problem is actually in PPI – which Perl::Metrics::Simple uses to parse the code. And there’s already a ticket to add all of the new keywords to PPI. Sadly, I don’t think my Perl is up to taking on this fix for the PPI team.

Given that the PAUSE issue I mentioned before has now been fixed, when I came to release App::LastStats recently I didn’t add the extra package line that had become my habit. It turns out that was a mistake. While my new module sailed past PAUSE, it seems that the lack of a package definition confuses MetaCPAN too. While my new module was being indexed by PAUSE and ending up in the 02Packages file correctly (so it was installable using tools like cpanm), it wasn’t appearing in MetaCPAN search or on my author page. Chatting with Olaf Alders on the #metacpan IRC channel, he spotted that the status of the release wasn’t being set to “latest” by the MetaCPAN ingestion code. Adding the same package line to the code soon fixed that problem too. Hopefully I’ll be able to work out where to fix the MetaCPAN code so it recognises class as a synonym for package. But, until that happens, anyone uploading a module to CPAN that uses the new syntax (is that really only me?) will need to add the package line.

There’s one more class of problem that I’m still trying to work out. And that’s down to my use of Feature::Compat::Class to make these modules compatible with versions of Perl that don’t support the new syntax. Part of the problem here is that we now have two versions of Perl that support the new syntax – 5.38 and 5.40. But they support slightly different versions of the syntax – that’s to be expected, of course; it’s how the new feature is being written.

The way that Feature::Compat::Class works is that it checks the version of Perl and if it is running on a version less than 5.38, then it loads another module called Object::Pad – which is a test bed for the new class syntax. Object::Pad supports more of the planned new syntax that has been actually released yet. So when Feature::Compat::Class loads Object::Pad, it uses a flag which tells Object::Pad to only allow the syntax that has been released in a Perl release. But which syntax? From which release? I guess it depends on which version of Object::Pad I’m using. Presumably, a version that was released after Perl 5.40 will support all of 5.40’s new syntax. And if I write code that uses the newest syntax, what happens when someone tries to run it on Perl 5.38? Currently, I’m only using 5.38’s syntax, so I’m not sure yet. And this is a problem that will get worse as future versions of Perl add more features to the class syntax.

I don’t think my new modules have many users – they’re very niche, so this is probably only a problem that I need to solve for myself. And I’m solving it by running the code in Docker containers that have the latest version of Perl installed. But it’s something I’ll need to think about more deeply if any of these modules become more widely used. Maybe I just encourage people to use them via the Docker images.

Oh, one final thing. The new class syntax is experimental. Some people would, I suppose, say that’s a good reason not to use it in CPAN module – but, hey, bleading edge 🙂 But that means it produces loads of “experimental” warnings if you don’t explicitly add code to suppress then. That code is no warnings 'experimental::class'. But that doesn’t compile on a Perl earlier than 5.38 (because it’s not a recognised warning category on a version of Perl where the feature is unimplemented). So I need to look at using if to only turn off those warnings on the correct versions of Perl.

I don’t want to put anyone off using the new class syntax. I think it’s a great new tool and I’m looking forward to seeing it become more powerful as each new version of Perl is released. I just want people to realise that you will hit certain speedbumps by being an early adopter of features like this.

Have you tried the new syntax? What do you think of it?