Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79676
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Stanislav Malyshev <smalyshev@gmail.com>
Message-ID: <548F5CF3.7070807@gmail.com>
Date: Mon, 15 Dec 2014 16:13:07 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
CC: internals@lists.php.net
References: <B6.00.14066.691CC845@pb1.pair.com> <alpine.DEB.2.11.1412132316440.4080@whisky.home.derickrethans.nl> <548CDF7F.3060805@gmail.com> <548F406B.1010908@gmail.com>
In-Reply-To: <548F406B.1010908@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
From: leeoniya@gmail.com (Leon Sorokin)

On 12/15/2014 2:11 PM, Stanislav Malyshev wrote:

> There's not that many breaking changes accepted, and each of them had to
> be substantiated. "We had other breaking changes" is not a
> substantiation. For example, "most uses of associativity are wrong ones"
> - is, but that makes the idea of un-associating it even better, since
> unlike changing the associativity, it actually makes the problem obvious
> and easy to fix. Alternatively, of course, we could make a tool that
> detects this and alerts the user, but making it loud still sounds better.
> And the breakage we are discussing is not "trivial" - it's a logic
> change which makes code silently take different codepath without anybody
> knowing. In the world of BC breaks, this is one of the most evil ones.
> So we should avoid it as much as possible.

The justification for not making breaking changes always grows as a 
function amount-of-code-in-the-wild which could possibly be relying on
bugs.

This situation results in a permanent conclusion of 'better-never' in 
lieu of 'better-now-than-later'. In PHP-land, the implication then is 
that this gridlock cannot be resolved even by major versions (IMO, one 
of very few reasons for major versions to exist *at all*).

> Usually the burden of proof lays on whoever proposes the change. Note
> that a lot of code is not public, especially for languages like PHP that
> is used for websites - meaning, there's little reason to publicize any
> code but reusable library code. And the fact that the change would not
> break a handful of popular libraries doesn't mean it won't break scores
> of websites whose source you can not see, but which are way more
> important for the people using them than some library they don't use.
>
> Yes, I understand that this means very high burden on somebody proposing
> BC-breaking change, and it makes the development more conservative. It
> is a high burden convince people that this change is worth the risk of
> breaking potentially unknown code with unknown consequences.

Without telemetry, there is obviously no way of *ever* asserting that 
something is ripe for removal or even deprecation. So this burden of 
proof is unmeetable by definition.

--
Leon Sorokin