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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
