Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
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: Thu, 21 Aug 2014 12:41:35 -0700
Message-ID: <CAKOpQSzmHfSH1VTn5WqXSJ4Cj59eq00NYweK4xt9DEV1tsBuMQ@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011844ce8eabc4050128e8d7
Subject: Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC]
 Integer Semantics)
From: kris.craig@gmail.com (Kris Craig)

--089e011844ce8eabc4050128e8d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 21, 2014 at 8:30 AM, 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 integer=
s
> > > 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
>
> 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
>

Derick, I think you misunderstood my meaning.  It was never my intention to
imply that BC doesn't matter or that it should be taken lightly.  My
statement that it's not an issue was in the context of this RFC, which
people seem to overwhelmingly agree is a good idea.  When you have a
beneficial idea that people like, implemented in a major version increment,
BC is not an issue.  That's what I meant and I stand by that.

That said, I don't disagree with your larger points about BC being a
consideration even in major release increments.  However, I also feel the
need to point out that, historically, there have been a lot of known issues
in PHP that we've decided not to fix even in major increments because of
what I believe to be an excess of BC concern.  One example-- it's almost a
cliche at this point-- is the inconsistent function naming and argument
orders.  In my experience, that's been the most common complaint I hear
from PHP devs.  We've avoided cleaning that up because it would break all
kinds of stuff.  While I agree that BC should never be decided on lightly,
I do believe that an expectation exists that significant code updates will
have to be made by framework/etc maintainers when upgrading to a new major
release.  So I do think we should allow ourselves to finally correct these
lingering issues for the next major release.  It will slow adoption in the
short-term, but it is the right strategy for the language in the long-term.

TL;DR:  BC does matter and should never be taken lightly, but we should
also not be afraid to introduce some BC in a major release in order to
correct various longstanding issues.

--Kris

--089e011844ce8eabc4050128e8d7--