in reply to The need and the price of running on old versions of Perl

It's not always a matter of being afraid to upgrade Perl. For example, Solaris 8 came with Perl 5.6 or 5.005. Perl wasn't used on that machine for a big program but for convenient small utility programs that created human readable diffs. Having modules needlessly require higher versions of Perl would have lessened the utility of Perl on that platform by much.

I am not against using features when they are useful. I almost always use three-arg open() and qr// whenever they are needed. But especially our is a useless feature that introduces a 5.6 dependency which is completely unneeded - use vars qw() achieves (almost) the same, except that you have to refer to a global variable by its global name from outside the package, which I consider more correct.

For example, one of my modules, parent works with Perl down to 5.004, and Maddingue helped me weed out the compatibility problems that only existed in the test suite. Often, little fixes restore backwards compatibility and if you want your code to be used, thinking of backwards compatibility makes it easier for your users to actually use your code in their environment.

Replies are listed 'Best First'.
Re^2: The need and the price of running on old versions of Perl
by szabgab (Priest) on Sep 18, 2007 at 12:51 UTC
    this is an excellent point however:

    What do you mean by needlessly?

    You can write (almost) everything on Perl 5.000. Hey you could even do that in Perl 4 syntax using require... So why do we expect (and let our users expect) that modules will always work on old version of Perl? This creates needless (here it comes :-) extra work to the module developers.

      I cannot speak for that hypothetical "we", but I as a module developer support my users because I want my code to be useful and used. This means that I don't want to place an undue version burden on my users, especially when I am one of my module users. I cannot easily upgrade the Perl versions I have available, and hence want my code to be both, conveniently maintainable on one side and conveniently working on the other side.

      For me, this means that I use whatever features I see fit - for example I often use the three-argument open, but I never use our, because the benefit of our is not existent. It's not "big extra work" for me because I mostly know what breaks between the major versions of Perl, and that "little extra work" usually pays off when I encounter a machine with only 5.005 on it.