Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > split() and @_: Perl changed between 5.8 and 5.14

Reply
Thread Tools

split() and @_: Perl changed between 5.8 and 5.14

 
 
Kenny McCormack
Guest
Posts: n/a
 
      12-12-2012
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.)
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) (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.

 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      12-12-2012
In article <(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:
>
>Quoth (E-Mail Removed) (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 -

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
Ben Morrow <(E-Mail Removed)> 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.

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
(E-Mail Removed) (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'.
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      12-12-2012
On 2012-12-12 14:05, Ben Morrow <(E-Mail Removed)> wrote:
>
> Quoth (E-Mail Removed) (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
| | | (E-Mail Removed) | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> 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 ****ed 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.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> > Quoth Rainer Weikusat <(E-Mail Removed)>:
>> >> Ben Morrow <(E-Mail Removed)> 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).
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      12-12-2012
Ben Morrow <(E-Mail Removed)> 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.
 
Reply With Quote
 
Peter Makholm
Guest
Posts: n/a
 
      12-13-2012
Ben Morrow <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
mismatch between Perl 5.6 and Perl 5.8 in printing high precisionvalues. vivekanand.naik@gmail.com Perl Misc 19 04-07-2008 01:12 PM
changed state to up changed state to down FastEthernet LINEPROTO-5-UPDOWN surrealarmada@gmail.com Cisco 3 03-07-2007 06:06 PM
Has comparison of instancemethods changed between python 2.5 and 2.4? Frank Niessink Python 0 12-15-2006 04:38 PM
scroll position is changed when style is changed? mxbrunet Javascript 1 11-03-2006 03:40 AM
xmlDocument.Save "&#10;" getting changed changed to "&amp;#10" st@jpa.co.jp ASP .Net 1 10-11-2005 01:30 PM



Advertisments