Code should be version-aware

[ajdelore]

I use perl 5.005_03. It is what the sysops have installed on my server, and the default perl that came on my NT box at work. I don't really plan to upgrade, as this would involve installing a local perl (and eating up my home disk quota), and honestly I don't have any problems.

I am sure that there is still a lot of 5.005 out there, as well as 5.6 and 5.8. While the differences aren't dramatic, it only takes one line to make a program fail.

I think that, in light of the many versions out there, code authors need to be sure they think about this when coding -- and many do. It should become a new standard for robust code, along with strict and warnings.*

The bigger question is, of course, at what point do you continue to code for older versions, and at what point do you give them up? This is very much analagous to the situation with html and web browsers.

However, I don't want to go there right now. What do other monks think? Should it be best practice to start all programs with:

#/usr/bin/perl -w

use strict;
require 5.X;

* Of course, use warnings; instead of -w will fail on 5.005!!

</ajdelore>

[Abigail-II]

This is very much analagous to the situation with html and web browsers.

No, it's certainly not. Web browsers are mostly used by end users, people who hardly have any knowledge on how to install software. Furthermore, there are many browsers and many platforms; for webpages it's good to be conservative.

OTOH, writing programs or module, which will only run on the newest version of Perl is not a problem. A box can have many installations of Perl. People seem to have this notion that there can only be one version of Perl on a machine, and never ever more than one. This is of course utter bullshit. Boxes regulary have several complete Java installations, because an application comes with its own Java environment. That's how you should roll out a Perl based application as well (and believe me, there are more application that you'd think that work that way). Just deliver your application with the appropriate Perl versions/configuration/modules.

And note that it's not just the Perl version you have to take care off. Threads as well. 64 bit integers. 64 bit pointers. Large file support. Choice of random generator. Perlio, sfio or stdio? Perl malloc or system malloc? GCC, native compiler, or something else?

Should it be best practice to start all programs with:

#/usr/bin/perl -w

And turn on warnings for code that might not be warning free? I don't think so. 5.6, the version that gave us lexical warning is three years old. If all new code would have to be backwards compatible with old Perl versions, there wouldn't be any initiative to further develop Perl.

If you prefer using ancient, unsupported, versions of Perl, that's ok. But it's unreasonable to ask people who write new code not to use three year old features because your ancient versions can't support them. You will just have to satisfy yourself with old versions of the modules - you're satisfied with an old version of perl itself as well.

Abigail

[BUU]

I think your missing his point. I'm not certain, but I'm fairly sure that his point was not that everyone should write modules for 5.006 or whatever, but that modules should know what their minimum required perl version is and say so explicitly.

[Abigail-II]

I was responding to:

The bigger question is, of course, at what point do you continue to code for older versions, and at what point do you give them up? This is very much analagous to the situation with html and web browsers.

which to me clearly talks about coding for older versions, and not about putting in a 'use 5.8' of some sorts.

Abigail

[ajdelore]

Exactly... As I said in the OP, I wasn't trying to suggest that people need to code for older perl versions. I was just suggesting that, much the same as use strict; has become basically a standard for good coding practice, so should software being version-aware.

As other monks have pointed out, I suppose I should add the caveat that code should be version-aware when it is using features that will break older versions.

In addition to a require/use version statement, putting something in the POD will alert users before they download and try to use the script/module/code.

This is not because I think that people should continue to use perl 5.005, but simply in acknowledgement of the fact that many people do use perl 5.005.

Authors should certainly use features available in higher versions -- that isn't my point. My point is, just make your code (and POD) reflect this.

Finally, re: Abigail-II's comments, I think there is an analogy between perl and HTML. There are a lot of people out there downloading CGI scripts and running them on commercial web hosts who are basically clueless end users when it comes to perl. They don't know what version of perl they have, and wouldn't know how to upgrade it if they did.

Also, you need access to the shell to do it -- not everyone has this, or else they have limited disk quotas that would not handle the installation.

However, the point I was really trying to make was from a programmer's perspective. HTML authors are always fooling around trying to make sure their fancy new layouts look alright in older browsers. At some point, you just have to write off Netscape<=4 or what have you. Similarly, if you are coding for an unknown user-group (ie a CGI script or something like that), at what point do you say "I don't care if this doesn't work in version X."

Of course, I wasn't trying to open this can of worms. :)

</ajdelore>

[Aristotle]

ajdelore was asking you to put require 5.008; at the top of your 5.8 code (and respectively for other versions), not write code for 5.5.3.

Makeshifts last the longest.

[mpeppler]

Boxes regulary have several complete Java installations, because an application comes with its own Java environment. That's how you should roll out a Perl based application as well (and believe me, there are more application that you'd think that work that way). Just deliver your application with the appropriate Perl versions/configuration/modules.

Indeed. When I was working on adding perl functionality to Sybase's OpenServer and XPserver I realized that there was no way to provide this in a coherent manner without shipping the whole perl interpreter compiled in a manner consistent with the functionality that I needed.

Michael

[hardburn]

What does your environment look like? Personally, I write scripts that will run on my employer's web server. I know what versions of Perl are installed and where they are located on the server. The programs don't need to be version aware, because they are in a controled enviroment.

Now, if I was writing code that would be released to the public, I'd be a little stricter about version control.

The question of when to drop old software is not a small one. There will probably be somebody running Win 3.1 in 2057. It won't be pretty, and there will only be a few geezers around that remember how to work the fool thing, but if it gets the job done . . .

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

[PodMaster]

Should it be best practice to start all programs with

No. As a cpan-tester, i see far too many modules (created by h2xs), which have use 5.008; when they aren't using any 5.008 specific features.

I think it's a good idea to inlude use VERSION but only if you are sure that VERSION is the minimum required version of perl, and you're doing this because you're using a perl feature which was introduced in VERSION.

You should not use 5.006; because that's when the warnings pragma was first introduced.
You should only use 5.005; because that's when the qr operator was first introduced, and you're using qr in your program.
You should not guess. If you don't know if your program uses perl features which were not available in some VERSION of perl, don't guess, just leave out the use VERSION; statement.

Now I realize you said "require", but I prefer compile-time checking, and seeing how the use VERSION; syntaxt was first introduced in perl 5.004, some might prefer to use BEGIN { require VERSION } when appropriate ;)

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

[waswas-fng]

I agree with Abigail-II, as long as the documentation for public code states its minimum required version of perl, you as the "user of stuff old and dusty" should be responsible for dealing with the broken module. heck if I will use -w when everything I develop for/on supports use warnings; and has for at least 3 years. I say if your needs require you to be stale it is your onus to deal with it -- not the comunity at large.

-Waswas

[Jenda]

As far as use warnings; is concerned ... i strongly believe there should be some (even "fake") warnings.pm module for perl 5.005 (or even older versions). I don't really mind if no warnings 'foo' turns off warnings completely in older perls, but the fact that as soon as you use warnings the code is incompatible with older perls is really annoying.

Actually ... there seems to be a rather easy way to make sure use warnings doesn't kill the script without having to add any file anywhere :

BEGIN {
    $INC{'warnings.pm'} = 'ignore'
        if ($] < 5.006 and !exists $INC{'warnings.pm'}) ;
}

Of course this makes the use warnings ... completely ignored.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

[liz]

...there should be some (even "fake") warnings.pm module for perl 5.005 (or even older versions)..

This was extensively discussed at the p5p BOF at the YAPC::Europe in Paris. It was decided however, to not take any action at this point. The reason for this is that all the repercussions with regards to CPAN are not clear yet. You don't want the fake warnings.pm replace your "real" one when you're installing a module from CPAN, or have your perl upgraded to 5.8.1 when installing the fake warnings.pm, etc. etc.. CPAN (particularly the indexer) needs to become more flexible. This work is currently underway.

In the mean time, I put this warnings for modules < 5.6 in Snippets.

Liz