NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/perl/6926

Text File | 1992-11-10 | 1.7 KB | 40 lines

Newsgroups: comp.lang.perl
Path: sparky!uunet!panther!mothost!merlin.dev.cdx.mot.com!fendahl.dev.cdx.mot.com!mcook
From: [e-mail] (Michael Cook)
Subject: Re: scripts should indicate the Perl version (a proposal)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: fendahl.dev.cdx.mot.com
Organization: Motorola Codex, Canton, Massachusetts
References: <[e-mail]> <[e-mail]>
Date: Tue, 10 Nov 1992 14:01:02 GMT
Lines: 27

[e-mail] (Christopher Davis) writes:

>MC> == Michael Cook <[e-mail]>

> MC> How about this idea: There should be a way to specify in a Perl
> MC> script what version of Perl the script was written for.  Then, as
> MC> new keywords and other non-backwardly-compatible functionality are
> MC> added, old scripts could still likely work correctly.

>(The real solution would be not to use lower case unquoted strings, and
>trust in Larry not to break anything.  Or hard-code the version, say:
>#!/usr/local/bin/perl4.035 -- #-*-Perl-*-)

You have a particular class of incompatibilities in mind.  What about those
like the hack that enables bitwise operations on strings: perl searches for
use of the keyword 'vec'.

Larry says that Perl 5.0 may let us invoke subroutines by doing foo() instead
of &foo().  Does that mean we have to pick a new naming convention for
subroutines, such as FOO() or Foo(), to avoid using future keywords?  There
may be a clever fix for this conflict, too.  But maybe there's a generalized
solution...

BTW, the "version specifier" should have file scope.  A require'd file might
have been written for a different version of Perl.

Michael.