Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76786
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <alpine.DEB.2.11.1408201003330.4107@whisky.home.derickrethans.nl>
References: <alpine.DEB.2.11.1408201003330.4107@whisky.home.derickrethans.nl>
Date: Fri, 22 Aug 2014 10:26:43 +0800
Message-ID: <CABBJUpdcDtsyqyrT24c5o-pQ9v5xdpaxNT8WQTwdGNsOg9yh6w@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC]
 Integer Semantics)
From: laruence@php.net (Laruence)

Hey:






On Thu, Aug 21, 2014 at 11:30 PM, Derick Rethans <derick@php.net> wrote:
> On Tue, 19 Aug 2014, Kris Craig <kris.craig@gmail.com> wrote:
>
>> On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>> > I have made an RFC which would make some small changes to how integers
>> > are handled, targeted at PHP 7:
>> >
>> > https://wiki.php.net/rfc/integer_semantics
>> >
>> > Thoughts and questions are appreciated. Thanks!
>>
>> <snip>
>>
>> And since you're targetting the next major release, BC isn't an issue.
>
> This sort of blanket statements that "Backwards Compatibility is not an
> issue" with a new major version is extremely unwarranted. *Extreme care*
> should be taken when deciding to break Backwards Compatibility. It
> should not be "oh we have a major new version so we can break all the
> things"=E2=84=A2.
>
> There are two main types of breaking Backwards Compatibility:
>
> 1. The obvious case where running things trough ``php -l`` instantly
>    tells you your code no longer works. Bugs like the two default cases,
>    fall in this category. I have no problem with this, as it's very easy
>    to spot the difference (In the case of allowing multiple "default"
>    cases, it's a fricking bug fix too).
>
> 2. Subtle changes in how PHP behaves. There is large amount of those
>    things currently under discussion. There is the nearly undetectable
>    change of the "Uniform Variable Syntax", that I already `wrote
>    about`_, the current discussion on `"Binary String Comparison"`_,
>    and now changing the `behaviour`_ on ``<<`` and ``>>`` in a subtle
>    way. These changes are *not okay*, because they are nearly
>    impossible to test for.
>
>    Changes that are so difficult to detect, mean that our users need to
>    re-audit and check their whole code base. It makes people not want to
>    upgrade to a newer version as there would be more overhead than
>    gains. Heck, even changing the ``$`` in front of variables to ``=C2=A3=
``
>    is a better change, as it's *immediately* apparent that stuff
>    changed. And you can't get away with "But Symfony and ZendFramework
>    don't use this" either, as there is so much code out there

I am totally agree with Derick here.

We should avoid to change such basic behaves..

thanks
>
> As I said, the first type isn't much of a problem, as it's easy to find
> what causes such Backwards Compatibility break, but the second type is
> what causes our users an enormous amount of frustration. Which then
> results in a lot slower adoption rate=E2=80=94if they bother upgrading at=
 all.
> Computer Science "purity" reasons to "make things better" have little to
> no meaning for PHP, as it's clearly not designed in the first place.
>
> Can I please urge people to not take Backwards Compatibility issues so
> lightly. Please think really careful when you suggest to break Backwards
> Compatibility, it should only be considered if there is a real and
> important reason to do so. Changing binary comparison is not one of
> those, changing behaviour for everybody regarding ``<<`` and ``>>`` is
> not one of those, and subtle changes to what syntax means is certainly
> not one of them.
>
> **Don't be Evil**
>
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



--=20
Laruence  Xinchen Hui
http://www.laruence.com/