develooper Front page | perl.perl5.porters | Postings from July 2009

Back and forth compatibility (Re: [PATCH] Remove implicit split to@_)

Thread Previous | Thread Next
From:
Michael G Schwern
Date:
July 11, 2009 15:15
Subject:
Back and forth compatibility (Re: [PATCH] Remove implicit split to@_)
Message ID:
4A590EF8.6070207@pobox.com
Abigail wrote:
> On Fri, Jul 10, 2009 at 02:42:01PM -0700, Chip Salzenberg wrote:
>> [ SUMMARY: Only C<use 5.012> may disable split assignment to @_. ]
>> [ METASUMMARY: Let's put this to bed.  Surely there are bigger fish to fry. ]
>>
>> Michael G Schwern <schwern@pobox.com> writes:
>>> Making it a compile-time error isn't compromise, its picking the lowest common
>>> denominator.
>> Compromise makes bad design.  Synthesis can make good design.  They're easy
>> to mistake for each other, because both involve listening and adapting.
>>
>> Let's spell out the scenario of just changing split:
>>
>>   1. split in scalar context no longer assigns to @_.
>>       the syntax of split does not change, only its semantics.  <--- vital point
>>   2. people write code in Perl 5.12 that depends on the new semantics
>>   3. it's syntactically valid Perl 5.10, 5.8, 5.6.1, etc.
>>   4. when fed to those older Perls, the code compiles, but runs incorrectly
>>   5. users feel they've been unfairly played
>>   6. they're right
>>
>> Breaking upward _or_ downward compatibility *silently* without a damn good
>> reason is impolite.  I like to be impolite only for good reason.  ("I don't
>> believe in breaking small laws." -- The Rebel Set)
> 
> 
> Well, it's not really silent. It has been given a deprecated warning
> since at least 5.6.x. But I appreciate the reasoning.

5.000.  (Which is part of why I'm tearing my hair out here over this debate)

So at step 4 they get a clear deprecation warning that something different is
going on.  The desired behavior (returning a count in scalar context) is the same.

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.

What Chip's talking about is writing NEW code on a NEW perl which may also be
run on an OLD perl and ensuring it has the old effect... or errors or warns.
We've never really worried about that before.  I'm not even sure what sort of
compatibility that is.  Back and forth compatibility?

For example, when the ability to use lexical filehandles was added in 5.6 we
didn't worry that someone might start using them on 5.5 code without a "use
5.006" line.  It didn't work and gave an error and that was considered enough.
 When we added a lexical iterator to for we didn't worry about 5.003 code, it
would just error out.  When reading from a scalar ref was added to open() in
5.8 there's nothing which shields 5.6 users from getting the wrong behavior
(that one, incidentally, does not give a good error or warning).

The assumption has been that if you use new features you add in a "use 5.0x"
line and that's the programmer's responsibility.  In practice its kind of
indifferently done.

Should we worry more about this?  Perhaps.  This came up at YAPC where "use
5.012" really means "I expect Perl to run as it did in the 5.12 series" as
opposed to "I'll work on 5.012 OR HIGHER".  Technically it means the latter.
In reality it means the former.  It has the potential to radically complicate
the code littering it with code implementing alternative behaviors.  And we'd
have to nail down the issue of "how far back do we support" which has never
been nailed down.

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?


-- 
29. The Irish MPs are not after "Me frosted lucky charms".
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
           http://skippyslist.com/list/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About