in reply to Code should be version-aware

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

[download]

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

Replies are listed 'Best First'.
Re: Re: Code should be version-aware
by BUU (Prior) on Aug 12, 2003 at 02:34 UTC
    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.
[reply]
      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

[reply]

      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>

[reply]
[d/l]
Re^2: Code should be version-aware
by Aristotle (Chancellor) on Aug 12, 2003 at 03:00 UTC
    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.

[reply]
Re: Re: Code should be version-aware
by mpeppler (Vicar) on Aug 12, 2003 at 08:08 UTC
    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

[reply]

In Section Meditations