Front page | perl.perl5.porters |
Postings from October 2009
Re: do SUBROUTINE(LIST)
From: Tom Christiansen
October 27, 2009 11:15
Re: do SUBROUTINE(LIST)
Message ID: 23732.1256667332@chthon
>> I still have 23,467 lines of code strewn across 50 files which all
>> run unattended perfectly well today--some every day--and which you
>> would by this change break. As I've said, I've no personal affection
>> for the construct; I don't use it and I don't teach it to others.
> We aren't going to retrospectively change all your installed perl
> interpreters. They are only going to break *if* you upgrade your perl.
I suppose that I *could* do that. So I guess I could do a mass edit of
the #! lines for these 50 files I didn't realize I had. I've never
before kept legacy perl binaries around because some release had broken
code. I've updated that code instead. This was a small handful, not
more than a dozen IIRC, for perl5, and it was about there for perl5.10.
But that's no tenable long-term solution. I run under 4-5 platforms,
some of those with several machines each. I am accustomed to perl
programs being portable to any of those systems that have a perl
interpreter on them. I think that is part of the point, actually.
I would no longer have a portable set of tools to carry with me wherever
I go. Places I go are not always ones where I'm free to diddle the perl
installation. If my tool chest no longer runs under standard perl, I
have a problem.
Having to maintain multiple perl binaries and contend with maachine-
dependent #! lines is going to be enough of a long-term hassle that I
hope I'd be smart enough to thrown in the towel early.
So that means hand editing them all anyway.
> If they upgrade their perl interpreter at all.
> IF THEY UPGRADE THEIR INTERPRETER.
> And, if they *do* want to upgrade /usr/bin/perl to be a newer version,
> NOTHING stops them keeping the EXISTING WORKING INTERPRETER and changing
> the #! line on the scripts that run with an older version.
Ok, your refrain is clear enough, but I think it's not really right. Andy
sees the trouble. And sure, I can do that on my systems. It's not much
fun, but I could. But it means I no longer have a portabale toolchest.
So no, I can't do that. I have to edit all my files.
> Heck, I could see an argument that they're being daft if they want things
> to keep working, yet have the #! point at /usr/bin/perl
Really? Wanting things to keep working is daft?
> So, I seriously think you're overplaying the "everything will break if you
> even think about it" fear that your message reads to me as.
It's because I thought I'd check into this before speaking up. It wasn't
until I did so that I saw how much trouble it was. I checked my ~/scripts/
directory for non-conformant code, and was very surprised. I looked at the
many releases of perl around 5.004, and I looked at each of perl1 .. perl5.
That's why I concluded that you'd be orphaning and inconvenience a loit
more than appears safe.
I wonder how may of Larry's programs this would break, or those from
anybody who wrote Perl scripts before perl5? Perl5 was never intended to
obsolete prior code en masse; in fact, it intended the opposite. This no
longer seems to apply, does it?
> Yes, there is rational discussion to be had about what can go.
> And heck, "3% of the grammar is this 1 feature deprecated over a decade ago"
> strikes me from a maintainer's point of view as actually a good reason to
> consider removing it. It's not getting any easier to
> a: maintain perl
> b: encourage other people to maintain perl
I thought hard about that one, about whether it's actually a good reason.
It has its merits. But I decided I couldn't find much historical support
for breaking large amounts of code, excepting the two points I've
mentioned, and both of those were smaller than this.
In the historical record, I see a lot of bending over backwards for smaller
things than this, all in the interest of compatibility. I'd thought perl6
was going to be the big code-break point, and that even that would have a
compatibility story--but I guess I was wrong.
> and if you really want stable, you will soon get Jack Cohen's special
> word for it, because there will be no-one left to change anything.
Yes, and so too will I be, which I suppose would help.