Front page | perl.perl5.porters |
Postings from July 2009
Re: Back and forth compatibility
From: Michael G Schwern
July 11, 2009 20:41
Re: Back and forth compatibility
Message ID: 4A595B44.email@example.com
Ben Morrow wrote:
> Quoth firstname.lastname@example.org (Michael G Schwern):
>> This discussion brings up a new type of compatibility. Previously we've been
>> worried about backwards compatibility, that OLD code using OLD features still
>> runs fine on NEW Perls. Deprecation warnings are there to give notice and
>> removing a long deprecated feature is fine. So in that view simply removing
>> the implicit split to @_ with no further ado is fine.
> In this specific case I am inclined to agree. The more general question
> of changing the semantics of existing syntax is important, though, and I
> entirely agree with those who think we need a way to do it where we
> think it's a good idea. Here's a possible solution:
> 1. When we have seen 'use 5.012' or a 'use feature' that implies
> 5.12 in this lexical scope, you get the new behaviour.
> 2. When we haven't, you *still* get the new behaviour, but also a
> warning 'split in scalar context no longer sets @_ as of perl
> 5.12.0'. This warning will go away entirely with 5.14, so people
> get one major version of 'yes we really did mean it' to get the
Let me play devil's advocate.
If I were to deprecate something now, to be released in 5.12, I have to
deprecate it now, change the warning for 5.14 and in 5.16 finally remove it.
Or maybe we have to wait two major releases between deprecation and removal, I
forget. Either way, you're making it +1 major release.
All to protect code which doesn't have a "use 5.x" statement against a feature
which they probably weren't using anyway because it was deprecated and warned.
AND the damage has been done. Their code does not work because the feature
changed. They get a warning about it (if they had warnings on and pay
attention to it) but they get it after their business crashes. Yes, they
should have tested it but what we're trying to protect here is the idea that
one can write Perl and then just leave it in place and forget about it and
it'll run forever.
All of this is protecting against code which doesn't have a version statement.
If they did this wouldn't be a problem, Perl would be simpler, their code
would be safer.
I think the central issue here is this: What do we do when there's no version
statement? If code really wants to be compatible it either has to declare
what version of Perl it was written for. The alternative is that we A) guess
or B) go to ridiculous lengths to be compatible or C) tip-toe around with
hyper extended deprecation periods.
So I'll propose something radical next post.
> I would also like to see (maybe not for split, since the old behaviour's
> useless, but in general)
> 3. If you say 'use legacy "split"' you get the old behaviour for
> this lexical scope. This is harder than it seems, since to be
> useful it has to work
Most of the point of compatibility is to make it so people can just write code
once and not have to change it to work on new releases. This appears to be
catering to people who write code and then DO change it in the future and...
want to partially upgrade a bit at a time? If we support that I'd rather
support it by adding new features a bit at a time rather than turning on all
the new features and then removing them.
Python has "from __future__ import some_feature" for that. We have "use
feature". So in the case above you could say:
use feature "say";
The other use case here is that they actually want the legacy behavior. This
implies that changing it wasn't such a hot idea and there's no equivalent or
better new feature. I do not want to support such waffling in the design.
>> BUT since we've never done it that way before, can we make this policy
>> discussion orthogonal to this <weeping>very simple change to a looooong
>> deprecated and dangerous feature</weeping> and just patch it in?
> In this particular case, +1 :).
Thank you. :)
"I went to college, which is a lot like being in the Army, except when
stupid people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz