Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79672
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.50 as permitted sender)
Message-ID: <548F406B.1010908@gmail.com>
Date: Mon, 15 Dec 2014 12:11:23 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Leon Sorokin <leeoniya@gmail.com>, internals@lists.php.net, 
 Derick Rethans <derick@php.net>
References: <B6.00.14066.691CC845@pb1.pair.com> <alpine.DEB.2.11.1412132316440.4080@whisky.home.derickrethans.nl> <548CDF7F.3060805@gmail.com>
In-Reply-To: <548CDF7F.3060805@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The fact that it *may* break *some* code that is used somewhere despite
> documentation recommending against it (pretty much deprecating it
> already for years) is a terrible reason not to re-evaluate the situation
> given the huge opportunity to correct this.

It *will* break some code. There's no chance that somebody somewhere
doesn't use this. And the change would break it. Worse yet, he won't be
able to know about it until the customer complains about code logic
being broken.

> The only thing that's bonkers here is outright refusal to make trivially
> breaking changes (in addition to numerous other breaking changes already
> accepted) simply for the sake of not breaking some 0.00001% of outdated,

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.

> Rather than simply pointing to a 3-year-old close-reason, it would be
> prudent to actually get statistics on how often this unexpected behavior
> is relied upon in large, popular codebases. Packagist & Github, that

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. I think,
however, it's better than actually suffering these consequences.
Consider that however ugly this particular wart is, people has been
living with it for almost 20 years, and it may be preferable for them to
have somewhat ugly code than having broken code.

> It's short responses like this and the continued reliance on arguments
> posed in a different era/landscape that compel me to reconsider my
> continued participation in the PHP community at all.

Sorry, but arguing from "do this or that or I'm quitting" does not seem
a very strong argument to me. More drama does not help to evaluate the
merits of changing the associativity of ?:. I think everybody here
values the time of the volunteers that continue to contribute to the
project, but I think keeping the discussion on the technical merits
would be better.
-- 
Stas Malyshev
smalyshev@gmail.com