Re: do SUBROUTINE(LIST)

Front page | perl.perl5.porters | Postings from October 2009

Thread Previous | Thread Next

From:

Tom Christiansen

Date:

October 27, 2009 11:15

Subject:

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.

--tom

Thread Previous | Thread Next