I need to update Modern::Perl. I waited until the release of Perl 5.10.1. I'm going to add autodie as a dependency (but not enable it; that's for you to decide to use). I'm also going to load IO::Handle, per Yuval's suggestion in Are Filehandles Objects?.
Note that perl5i does this.
These are all simple and obvious changes. I've blocked on a larger change, related to a simple philosophical user interface question for the module:
What happens when what's "modern" changes?
Adding an installation requirement and loading two new modules won't hurt anything. It won't change any existing code. There are no compatibility concerns.
Future changes might have compatibility concerns. If you use Modern::Perl; by itself, you're taking a slight risk that you may have to revisit existing code after an upgrade. What's modern in August 2009 might not be as modern in August 2010 and certainly won't be modern in August 2019.
Elliot Shank wrote in A reasonable approach for Modern::Perl the example code:
use Modern::Perl as_of => '2009-06-23';What do you think?
I'd like to avoid complex date parsing where possible. I've also considered
changing M::P version numbers to dates like 2009.10.06. The
unification is tempting and the implementation is, at worst, of only modest
difficulty.
What do you think?
(One other requested change is to enable no Modern::Perl;. I'm
considering the best way to do so.)
You might want to consider limiting yourself to quarterly changes to what's "modern"
It'll make it a lot easier for your users to remember and understand.
I like the idea of Modern::Perl taking an optional date argument. I am not so sure that a day is necessary, as long as you don't plan on making more than 1 large change to Modern::Perl per month. So it would look like:
use Modern::Perl '2009-01';
I am not sure if the as_of hash key is going to help or confuse non-native English speakers. Prepositions are the devil.
I think just using the year would plenty granular. Perl releases seem more than a year apart, and a year buffer would give you enough time to see what trends really stick (instead of ending up including a module that is quickly replaced.)
Canonical YYYY[-MM[-DD]] is rather good without as_of
use Modern::Perl '2009';
use Modern::Perl '2009-10';
use Modern::Perl '2009-10-25';
And how about to include utf8->import?
Isn't it modern enough? ;)
I think both IO::Handle and FileHandle should be loaded for consistency.
blessed the handle will into FileHandle if its loaded, but IO::Handle otherwise. See http://gist.github.com/203984
This means that code relying on
might be working because a dependency has loaded FileHandle, but if that dep changed the code will start breaking.If you plan on releasing new versions of Modern::Perl with each new version of Perl, why not skip a new cognitive step (such as figuring out a new date based version scheme) and make the version equal to the version of Perl?
So to be clear as a dependency it will not be an 'option' of Modern::Perl? Thus, if we wanted to use it, we'd need to do:
and NOT something like:
If it's the later, then you might as well not add it, but if it's the former, that sounds like a great idea.