Adding Dates to Modern::Perl

| 12 Comments

The Modern::Perl metapragma needs some attention. I'd like to add autodie by default and enable unicode_strings on 5.12 and 5.14, but there's a dilemma.

This day was bound to come anyway. What was modern in 2009 for the Perl 5.10 era won't be modern soon.

I don't mind if you write use Modern::Perl; and get the most modern semantics of the version you have installed. (I'm tempted to check if the distribution is more than two years out of date and print a single warning that Perl 5 has marched on, but you may be able to talk me out of that.)

I think the best option for the module is to recommend the use of a date, as in:

use Modern::Perl 2010; # Perl 5.12 semantics
use Modern::Perl 2009; # Perl 5.10 semantics + autodie
use Modern::Perl 2011; # Perl 5.14 semantics

This helps document the intent of the code, as well as the degree of modernity (or decrepitude) of existing code which uses this metapragma.

I know how to implement this. What do you think of the interface?

12 Comments

I'd say using Perl release versions instead of years would be much more clear.

The years are sure cute and shiny, but on the other hand very unclear on their exact meaning. I mean, 2010 is a long time, that's 12 months. Does 2010 refer to the start of the year, or the end, or the middle? Who knows.

I've considered versions, but you have to have memorized release dates to compare a version number to the current date. I want users to be able to look at code in five years and say "Modern::Perl 2010? We should update!"

use YYYYMMDD or YYMMDD that way if you update more than once a year... and it's more readable that YYYYDDDD

I've considered that. It's fairly unlikely I'll make incompatible changes more than once a year, but it's possible.

perhaps it would be possible to use an date like YYYYMMDD if you want the modernity of that special day.
if you don't care about the special day/release than you could use the mor general YYYY that will activate the features of the most actual 2010 release.

Clearly it's time for Moderner::Perl. And in a few more years, Modernest::Perl.

Postmodern::Perl ? Maybe that's just Moose

I think its a good idea overall.

The YYYYMMDD syntax would be useful, but I'd like to see just YYYY supported as well if you go that route. You could just recognize YYYY as being equivalent to YYYY0101 for example.

I like the proposed interface including the date-based warning.

I'm probably going to say the obvious, but for releases within a given year, one could simply have the scheme:

YYYY.MM

So

use Modern::Perl 2011

refers to the state of modernism at the beginning of the year, whereas

use Modern::Perl 2011.05

refers to its state in May.

For more than one release a month, one could go the major.minor.rev route, but that's probably overkill.

I read

use Modern::Perl 2012

as "please enable the good-ish features of perl, circa 2012" and not as "use features available in perl as of 1 Jan 2012." I think the latter is...confusing, particularly once you're no longer anywhere near the time in question, where "near" means "what I can remember of the state of perl during 2012."

Too, I'd hate to need to fiddle with that statement during 2012. If I get the intent, it's meant to be a DTRT for me so I don't need to think about it.

So...its effects would change as 2012 progresses. I think that's OK.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on October 18, 2011 1:27 PM.

Two Paths Diverge was the previous entry in this blog.

Reimplementing the Wheel, not the Road is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?