[32692] in Perl-Users-Digest
Perl-Users Digest, Issue: 3837 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 3 14:55:57 2013
Date: Thu, 13 Dec 2012 02:17:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 13 Dec 2012 Volume: 11 Number: 3837
Today's topics:
Re: How comes (goes?) Perl 6? <brian.d.foy@gmail.com>
split() and @_: Perl changed between 5.8 and 5.14 (Kenny McCormack)
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <ben@morrow.me.uk>
Re: split() and @_: Perl changed between 5.8 and 5.14 (Kenny McCormack)
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <ben@morrow.me.uk>
Re: split() and @_: Perl changed between 5.8 and 5.14 <ben@morrow.me.uk>
Re: split() and @_: Perl changed between 5.8 and 5.14 <hjp-usenet2@hjp.at>
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <ben@morrow.me.uk>
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <rweikusat@mssgmbh.com>
Re: split() and @_: Perl changed between 5.8 and 5.14 <peter@makholm.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 Dec 2012 23:20:42 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: How comes (goes?) Perl 6?
Message-Id: <111220122320421156%brian.d.foy@gmail.com>
In article <ka8f5a$gb0$3@reader1.panix.com>, David Combs
<dkcombs@panix.com> wrote:
> I suppose this will be the final version of [Programming Perl] for perl-5?
When Tom and I were working on Programming Perl, 4th Edition, we had in
mind a book that could last several years. But, I can't say what will
happen with Perl 5 or if enough people will keep buying the book to
make it attractive to the publisher to update it. We're not thinking
about another update at the moment.
------------------------------
Date: Wed, 12 Dec 2012 13:01:52 +0000 (UTC)
From: gazelle@shell.xmission.com (Kenny McCormack)
Subject: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <ka9v80$qa5$1@news.xmission.com>
I have an old program that I wrote back in 2001, which has worked fine ever
since - right up until today, when I ran it for the first time in quite a
while. The script depends on the fact that (when it was written) when you
do split(), it puts the data into @_.
From what I can tell, the following are all true. Please confirm or deny:
1) In 5.8, this worked.
2) Somewhere along the way, this usage became "deprecated". I found a web
site that explicitly said that, while the usage is deprecated, it still
works, since if it was removed, old code (heh heh - such as mine) would
get broken.
3) In 5.14, it doesn't work. No error or warning message is generated, but
@_ is left unchanged.
P.S. I changed the program line from something like:
$x = @_[split(...)-1];
to:
@tmp = split(...);
$x = @tmp[@tmp-1];
And everything seems to be working fine now.
--
One of the best lines I've heard lately:
Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.
(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)
------------------------------
Date: Wed, 12 Dec 2012 13:39:15 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <87fw3bo0e4.fsf@sapphire.mobileactivedefense.com>
gazelle@shell.xmission.com (Kenny McCormack) writes:
[...]
> P.S. I changed the program line from something like:
>
> $x = @_[split(...)-1];
>
> to:
>
> @tmp = split(...);
> $x = @tmp[@tmp-1];
>
> And everything seems to be working fine now.
Assuming that all you're interested in is what would be the last
element of the list created by split, that your 'split regex' was
/ / and the unsplitted value contained in a variable named $v, you
could achieve the same with either
($x) = $v =~ /(?:.* )?(.*)/
or
$v =~ /(?:.* )?(.*)/ and $x = $1
This should also work when using any other 'split regex' instead of
the single space used in this example.
------------------------------
Date: Wed, 12 Dec 2012 14:05:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <ihfmp9-dh82.ln1@anubis.morrow.me.uk>
Quoth gazelle@shell.xmission.com (Kenny McCormack):
> I have an old program that I wrote back in 2001, which has worked fine ever
> since - right up until today, when I ran it for the first time in quite a
> while. The script depends on the fact that (when it was written) when you
> do split(), it puts the data into @_.
>
> From what I can tell, the following are all true. Please confirm or deny:
>
> 1) In 5.8, this worked.
Yes, with a warning.
> 2) Somewhere along the way, this usage became "deprecated". I found a web
> site that explicitly said that, while the usage is deprecated, it still
> works, since if it was removed, old code (heh heh - such as mine) would
> get broken.
This usage has been deprecated, and printing a warning, since 5.6. What
version of perl were you using in 2001?
> 3) In 5.14, it doesn't work. No error or warning message is generated, but
> @_ is left unchanged.
For 5.12 p5p finally got fed up and removed the feature entirely. split
in void context produces a warning, but split in scalar context can't,
since you might really have wanted just the count.
The general policy now is that you get one major version's worth of
deprecation warnings, and then deprecated features will be removed.
> P.S. I changed the program line from something like:
>
> $x = @_[split(...)-1];
Oh, *yuck*! You do realise this is implicitly populating @_ at the same
time as you're calculating its subscript?
Ben
------------------------------
Date: Wed, 12 Dec 2012 15:15:08 +0000 (UTC)
From: gazelle@shell.xmission.com (Kenny McCormack)
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <kaa71s$32q$1@news.xmission.com>
In article <ihfmp9-dh82.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth gazelle@shell.xmission.com (Kenny McCormack):
>> I have an old program that I wrote back in 2001, which has worked fine ever
>> since - right up until today, when I ran it for the first time in quite a
>> while. The script depends on the fact that (when it was written) when you
>> do split(), it puts the data into @_.
>>
>> From what I can tell, the following are all true. Please confirm or deny:
>>
>> 1) In 5.8, this worked.
>
>Yes, with a warning.
With the caveat that I probably don't have the warning level set high enough
(that's comp.lang.c-speak for it. In the perl world, I probably need some
extra library or something linked in), the fact is that I never got any
warnings on this.
One of the systems that runs this script is running Perl 5.8.6; I just
tested the script and it ran correctly, with no warnings generated.
>> 2) Somewhere along the way, this usage became "deprecated". I found a web
>> site that explicitly said that, while the usage is deprecated, it still
>> works, since if it was removed, old code (heh heh - such as mine) would
>> get broken.
>
>This usage has been deprecated, and printing a warning, since 5.6. What
>version of perl were you using in 2001?
As mentioned above, it runs fine with no warnings under 5.8 (today).
What version of Perl was current on Linux (x86), c. 2001?
>> P.S. I changed the program line from something like:
>>
>> $x = @_[split(...)-1];
>
>Oh, *yuck*! You do realise this is implicitly populating @_ at the same
>time as you're calculating its subscript?
Yup. That's why they call Perl a "write-only" language.
Anyway, thanks much for your response. It has answered my questions and
clarified my knowledge of the situation.
--
First of all, I do not appreciate your playing stupid here at all.
- Thomas 'PointedEars' Lahn -
------------------------------
Date: Wed, 12 Dec 2012 16:21:05 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <8762471bta.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> The general policy now is that you get one major version's worth of
> deprecation warnings, and then deprecated features will be removed.
I'm presently using perl 5.10.0 and 5.10.1 because these happen to be
the packaged perl versions available on the Debian (Lenny and Squeeze)
and Ubuntu (10.04) I need to support. Judeging from the current state
of the Debian unstable repository, the next perl version I will likely
need to support will be 5.14 which means that anything which got
deprecated in perl 5.12 will have been removed by then and insofar the
existing code I need to use happened to rely on such a deprecated
feature, it will just break silently. Presently, this is more than
30,700 LOC and I inherited some parts of it. I'm a single person and I
would be glad if I could get new code written as fast as my boss
would like to have it (who is already not overly happy with me using
Perl at all because it can't be compiled into some 'obscure' binary
format). All of this together is a very good argument for not using
Perl at all: At best, it is now one of many languages which mutate
quickly in unpredictable ways at the momentary whims of some
fluctuating set of people and anybody who isn't prepared to maintain a
private perl5 fork with the required set of features should rather
avoid it.
------------------------------
Date: Wed, 12 Dec 2012 16:26:18 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <871uev1bkl.fsf@sapphire.mobileactivedefense.com>
gazelle@shell.xmission.com (Kenny McCormack) writes:
[...]
>>> $x = @_[split(...)-1];
>>
>>Oh, *yuck*! You do realise this is implicitly populating @_ at the same
>>time as you're calculating its subscript?
>
> Yup. That's why they call Perl a "write-only" language.
A old joke-example of a German sentence goes like this: Derjenige, der
den Taeter, der den Pfahl, der an der Bruecke, die auf dem Weg nach
Worms liegt, steht, umgeworfen hat, anzeigt, erhaelt eine Belohnung.
The language doesn't use itself and if some text should be regarded as
'write-only' or not is entirely a matter of the style used to write
it: You may be 'a write-only coder' but Perl (minus you) is not 'a
write-only language'.
------------------------------
Date: Wed, 12 Dec 2012 17:15:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <fnqmp9-uia2.ln1@anubis.morrow.me.uk>
Quoth gazelle@shell.xmission.com (Kenny McCormack):
> In article <ihfmp9-dh82.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth gazelle@shell.xmission.com (Kenny McCormack):
> >> I have an old program that I wrote back in 2001, which has worked fine ever
> >> since - right up until today, when I ran it for the first time in quite a
> >> while. The script depends on the fact that (when it was written) when you
> >> do split(), it puts the data into @_.
> >>
> >> From what I can tell, the following are all true. Please confirm or deny:
> >>
> >> 1) In 5.8, this worked.
> >
> >Yes, with a warning.
>
> With the caveat that I probably don't have the warning level set high enough
> (that's comp.lang.c-speak for it. In the perl world, I probably need some
> extra library or something linked in), the fact is that I never got any
> warnings on this.
~% perl5.6.0 -we'split ":", "a:b"'
Use of implicit split to @_ is deprecated at -e line 1.
~% perl5.6.0 -e'use warnings; split ":", "a:b"'
Use of implicit split to @_ is deprecated at -e line 1.
~%
> One of the systems that runs this script is running Perl 5.8.6; I just
> tested the script and it ran correctly, with no warnings generated.
Then you aren't using 'warnings'. Why not? (I don't happen to have a
5.8.6 handy, but 5.8.4 produces the warning, as does 5.10.0.)
> >> 2) Somewhere along the way, this usage became "deprecated". I found a web
> >> site that explicitly said that, while the usage is deprecated, it still
> >> works, since if it was removed, old code (heh heh - such as mine) would
> >> get broken.
> >
> >This usage has been deprecated, and printing a warning, since 5.6. What
> >version of perl were you using in 2001?
>
> As mentioned above, it runs fine with no warnings under 5.8 (today).
5.8 is not 'today'. The last release of 5.8 was 5.8.9, four years ago.
The 5.8 branch has been officially unsupported since 5.12.0 was
released, in 2010. Even security bugs will almost certainly not get
fixed.
> What version of Perl was current on Linux (x86), c. 2001?
Don't know. Probably either 5.6.0 (2000), 5.6.1 (April 2001), or
5.005_03 (1999), depending on how up-to-date your distro of the time
was.
> >> P.S. I changed the program line from something like:
> >>
> >> $x = @_[split(...)-1];
> >
> >Oh, *yuck*! You do realise this is implicitly populating @_ at the same
> >time as you're calculating its subscript?
>
> Yup. That's why they call Perl a "write-only" language.
Perl is only write-only if you write it that way. You could have
perfectly well done it properly in the first place.
Ben
------------------------------
Date: Wed, 12 Dec 2012 17:04:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <02qmp9-uia2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > The general policy now is that you get one major version's worth of
> > deprecation warnings, and then deprecated features will be removed.
>
> I'm presently using perl 5.10.0 and 5.10.1 because these happen to be
> the packaged perl versions available on the Debian (Lenny and Squeeze)
> and Ubuntu (10.04) I need to support. Judeging from the current state
> of the Debian unstable repository, the next perl version I will likely
> need to support will be 5.14 which means that anything which got
> deprecated in perl 5.12 will have been removed by then and insofar the
> existing code I need to use happened to rely on such a deprecated
> feature, it will just break silently.
So, some time before that happens, build a 5.12 (or a 5.14) and test the
code on that. I'm sure that's not beyond you.
> Presently, this is more than
> 30,700 LOC and I inherited some parts of it. I'm a single person and I
> would be glad if I could get new code written as fast as my boss
> would like to have it (who is already not overly happy with me using
> Perl at all because it can't be compiled into some 'obscure' binary
> format). All of this together is a very good argument for not using
> Perl at all: At best, it is now one of many languages which mutate
> quickly in unpredictable ways at the momentary whims of some
> fluctuating set of people and anybody who isn't prepared to maintain a
> private perl5 fork with the required set of features should rather
> avoid it.
I did not institute this policy (though I happen to agree with it); I am
just telling people what it is. If you have a problem with it, take it
up with p5p.
Ben
------------------------------
Date: Wed, 12 Dec 2012 21:20:58 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <slrnkchppa.4h8.hjp-usenet2@hrunkner.hjp.at>
On 2012-12-12 14:05, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth gazelle@shell.xmission.com (Kenny McCormack):
>> I have an old program that I wrote back in 2001, which has worked fine ever
>> since - right up until today, when I ran it for the first time in quite a
>> while. The script depends on the fact that (when it was written) when you
>> do split(), it puts the data into @_.
[...]
>> 2) Somewhere along the way, this usage became "deprecated". I found a web
>> site that explicitly said that, while the usage is deprecated, it still
>> works, since if it was removed, old code (heh heh - such as mine) would
>> get broken.
>
> This usage has been deprecated, and printing a warning, since 5.6.
Even before that:
% /usr/bin/perl foo
Use of implicit split to @_ is deprecated at foo line 5.
...
% /usr/bin/perl -v
This is perl, version 5.005_03 built for i386-linux
Copyright 1987-1999, Larry Wall
...
I wouldn't be surprised if it was deprecated since 5.0.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 12 Dec 2012 20:58:09 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <87r4mvj8da.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > The general policy now is that you get one major version's worth of
>> > deprecation warnings, and then deprecated features will be removed.
>>
>> I'm presently using perl 5.10.0 and 5.10.1 because these happen to be
>> the packaged perl versions available on the Debian (Lenny and Squeeze)
>> and Ubuntu (10.04) I need to support. Judeging from the current state
>> of the Debian unstable repository, the next perl version I will likely
>> need to support will be 5.14 which means that anything which got
>> deprecated in perl 5.12 will have been removed by then and insofar the
>> existing code I need to use happened to rely on such a deprecated
>> feature, it will just break silently.
>
> So, some time before that happens, build a 5.12 (or a 5.14) and test the
> code on that. I'm sure that's not beyond you.
,----
| Presently, this is more than 30,700 LOC and I inherited some parts of
| it. I'm a single person and I would be glad if I could get new code
| written as fast as my boss would like to have it (who is already not
| overly happy with me using Perl at all because it can't be compiled
| into some 'obscure' binary format).
`----
It is certainly not 'beyond me' in a technical sense to spend 1 - 3
weeks with nothing but retesting working code and maybe another with
changing it such that it is again 'politically correct' for the
current definition of that. I could perhaps do this while on holiday,
but - unfortunately - I didn't have a single holiday since 2008, so
that's not really an option. It is certainly beyond the patience of my
employer to do this at any other time, though ...
For as long as nothing gets deprecated which I really do need (leaving
the issue with the inerited code, ie, code written by 'differently
abled' ex-colleagues and some heavily modified CPAN modules, aside),
everything is going to be fine and as soon as this does happen, I will
necessarily stop using newer Perl releases.
NB: This is not so much a statement about me but about the inherent
problems with any policy of this kind. As soon as people use code they
are not familiar with in detail (eg, because they happily download
everything CPAN has to offer :->), they're essentially fucked if
changes to the runtime environment used to run this code render it
incompatible with the version they're using and they will then either
dump this runtime environment altogether or 'opt out' of its future
development.
------------------------------
Date: Wed, 12 Dec 2012 22:02:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <mgbnp9-h8d2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >>
> >> > The general policy now is that you get one major version's worth of
> >> > deprecation warnings, and then deprecated features will be removed.
> >>
> >> I'm presently using perl 5.10.0 and 5.10.1 because these happen to be
> >> the packaged perl versions available on the Debian (Lenny and Squeeze)
> >> and Ubuntu (10.04) I need to support. Judeging from the current state
> >> of the Debian unstable repository, the next perl version I will likely
> >> need to support will be 5.14 which means that anything which got
> >> deprecated in perl 5.12 will have been removed by then and insofar the
> >> existing code I need to use happened to rely on such a deprecated
> >> feature, it will just break silently.
> >
> > So, some time before that happens, build a 5.12 (or a 5.14) and test the
> > code on that. I'm sure that's not beyond you.
>
> ,----
> | Presently, this is more than 30,700 LOC and I inherited some parts of
> | it. I'm a single person and I would be glad if I could get new code
> | written as fast as my boss would like to have it (who is already not
> | overly happy with me using Perl at all because it can't be compiled
> | into some 'obscure' binary format).
> `----
>
> It is certainly not 'beyond me' in a technical sense to spend 1 - 3
> weeks with nothing but retesting working code and maybe another with
> changing it such that it is again 'politically correct' for the
> current definition of that.
You like that phrase rather too much, but it's not relevant here. Code
which is even remotely clean will almost certainly not be affected by
deprecations. Features will not be deprecated randomly, only when they
are either universally (FSVO) agreed to be bugs, or when they are
actively impeding current development. Usually both would be required.
There is a large section of the p5p community which feel much as you do,
for much the same reasons, without necessarily being quite so dogmatic
about it. Jesse Vincent, the current holder of the pumpkin, is one of
them, so there's no need to panic about things disappearing without a
rather good reason.
> I could perhaps do this while on holiday,
> but - unfortunately - I didn't have a single holiday since 2008, so
> that's not really an option. It is certainly beyond the patience of my
> employer to do this at any other time, though ...
Any upgrade of any critical system comes with some risk of something
having been broken, intentionally or otherwise. This means that, from
time to time, time must be spent testing important systems against new
versions of software, and fixing them where necessary. The only
alternative is to wait until you are forced to upgrade (say, by the
discovery of an important exploitable security hole), at which point you
will have to jump production systems several major versions forward with
no testing and no rollback plan if things don't work out. If your
employer doesn't understand this you are doing them a disservice by
allowing them to remain ignorant.
> For as long as nothing gets deprecated which I really do need (leaving
> the issue with the inerited code, ie, code written by 'differently
> abled' ex-colleagues and some heavily modified CPAN modules, aside),
> everything is going to be fine and as soon as this does happen, I will
> necessarily stop using newer Perl releases.
Well, on your head be it. There have been one or two security holes
found in perl itself in the past; if you stop upgrading you won't get
fixes if any more are found. You will also, at some point, have to stop
upgrading any CPAN modules you deign to sully your hands with, at which
point you won't get fixes for security problems in *them*, either. Not
what I would call a very responsible approach to the problem.
> NB: This is not so much a statement about me but about the inherent
> problems with any policy of this kind. As soon as people use code they
> are not familiar with in detail (eg, because they happily download
> everything CPAN has to offer :->),
One of the major advantages of CPAN, as opposed to roll-your-own, is
that other people forward-port the code for you. There are modules that
get abandonded, but by and large any module that is commonly used will
end up getting picked up by someone else, simply because they need to
fix it for their own use.
> they're essentially fucked if
> changes to the runtime environment used to run this code render it
> incompatible with the version they're using and they will then either
> dump this runtime environment altogether or 'opt out' of its future
> development.
This problem is in no way specific to perl. Any piece of software will
have upgrades, some of which you will be obliged to install, and any
upgrade carries risk.
Ben
------------------------------
Date: Wed, 12 Dec 2012 22:46:19 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <87mwxikhxg.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> >> Ben Morrow <ben@morrow.me.uk> writes:
>> >>
>> >> > The general policy now is that you get one major version's worth of
>> >> > deprecation warnings, and then deprecated features will be removed.
>> >>
>> >> I'm presently using perl 5.10.0 and 5.10.1 because these happen to be
>> >> the packaged perl versions available on the Debian (Lenny and Squeeze)
>> >> and Ubuntu (10.04) I need to support. Judeging from the current state
>> >> of the Debian unstable repository, the next perl version I will likely
>> >> need to support will be 5.14 which means that anything which got
>> >> deprecated in perl 5.12 will have been removed by then and insofar the
>> >> existing code I need to use happened to rely on such a deprecated
>> >> feature, it will just break silently.
>> >
>> > So, some time before that happens, build a 5.12 (or a 5.14) and test the
>> > code on that. I'm sure that's not beyond you.
>>
>> ,----
>> | Presently, this is more than 30,700 LOC and I inherited some parts of
>> | it. I'm a single person and I would be glad if I could get new code
>> | written as fast as my boss would like to have it (who is already not
>> | overly happy with me using Perl at all because it can't be compiled
>> | into some 'obscure' binary format).
>> `----
>>
>> It is certainly not 'beyond me' in a technical sense to spend 1 - 3
>> weeks with nothing but retesting working code and maybe another with
>> changing it such that it is again 'politically correct' for the
>> current definition of that.
>
> You like that phrase rather too much, but it's not relevant here.
There was a time when someone considered split splitting into @_ in
scalar context a good idea. Presumably, at that time, someone whose
opinion differed from that was considered to be wrong. Most people
presumably didn't care: The feature existed. They either used it or
didn't use it. Then, times changed and the predominant opinion
changed, too, first to "this wasn't really a good idea" and then to
"it was such a bad idea that it needs to go away". This kind of
'opinion rotation' (whatever an issue at hand happens to be, their
will always people whose opinions on it differ and they're always all
convinced to have good reasons) is - completely correctly - referred
to as 'politics'.
[...]
> There is a large section of the p5p community which feel much as you do,
> for much the same reasons, without necessarily being quite so dogmatic
> about it.
I didn't write anything about my 'feelings', I described a technical
problem I could be facing and the options I have for dealing with it.
[...]
>> For as long as nothing gets deprecated which I really do need (leaving
>> the issue with the inerited code, ie, code written by 'differently
>> abled' ex-colleagues and some heavily modified CPAN modules, aside),
>> everything is going to be fine and as soon as this does happen, I will
>> necessarily stop using newer Perl releases.
>
> Well, on your head be it. There have been one or two security holes
> found in perl itself in the past; if you stop upgrading you won't get
> fixes if any more are found.
Can you imagine that people exist who couldn't care less about that
and that these people - more often than not - are in a position to
give orders to others? Again, I didn't write anything about my opinion
on this because it is completely irrelevant: In face of the options
a) spent a signficant amount of time testing or changing
working production code because someone made an incompatible
change to a new version of some infrastructure code
b) continue using the last known-to-be-working version
the only technically possible choice is b).
------------------------------
Date: Wed, 12 Dec 2012 22:54:38 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <87ip86khjl.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> as this does happen, I will necessarily stop using newer Perl releases.
>
> Well, on your head be it. There have been one or two security holes
> found in perl itself in the past; if you stop upgrading you won't get
> fixes if any more are found.
JFTR: I'm completely fine with fixing any issue in Perl which affects
me (this includes 'security problems') myself if there is no other
option. I'm already doing this with quite a few other 'large gobs of
C' (eg, Linux) where updateing isn't really feasible because fixing
the occasional problem can be done quickly while major 'redevelopment
efforts' (aka 'retest and change or rewrite existing code') is usually
not an option.
------------------------------
Date: Thu, 13 Dec 2012 10:28:46 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: split() and @_: Perl changed between 5.8 and 5.14
Message-Id: <87d2yenvw1.fsf@vps1.hacking.dk>
Ben Morrow <ben@morrow.me.uk> writes:
> There is a large section of the p5p community which feel much as you do,
> for much the same reasons, without necessarily being quite so dogmatic
> about it. Jesse Vincent, the current holder of the pumpkin, is one of
> them, so there's no need to panic about things disappearing without a
> rather good reason.
I believe that Ricardo Signes is the current holder. He took over from
Jesse somewhere in the 5.15 series. This doesn't change the above, as I
understand it Ricardo also supports the policies and goals championed by
Jesse.
//Makholm
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3837
***************************************
