Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79628
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <548CDF7F.3060805@gmail.com>
References: <B6.00.14066.691CC845@pb1.pair.com>
	<alpine.DEB.2.11.1412132316440.4080@whisky.home.derickrethans.nl>
	<548CDF7F.3060805@gmail.com>
Date: Sat, 13 Dec 2014 16:58:29 -0800
Message-ID: <CAKOpQSzmgzm4ED6X4rmAUn=9fQwc2ktP5bro9LG0Nf9+sFPakA@mail.gmail.com>
To: Leon Sorokin <leeoniya@gmail.com>
Cc: PHP internals list <internals@lists.php.net>, Derick Rethans <derick@php.net>
Content-Type: multipart/alternative; boundary=089e0139fc28c7f14c050a229f66
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
From: kris.craig@gmail.com (Kris Craig)

--089e0139fc28c7f14c050a229f66
Content-Type: text/plain; charset=UTF-8

On Sat, Dec 13, 2014 at 4:53 PM, Leon Sorokin <leeoniya@gmail.com> wrote:
>
> Respectfully,
>
> PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating; the
> utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind.
>
> > It is not a bug, as the issue's status says: "Not a bug".
>
> I can understand why this would have been a 'wontfix' for versions
> pre-7.0. However, major version changes are done primarily to fix these
> kinds of inconsistencies - that and marketing - and yes they are precisely
> that: bugs. Documentation of unexpected behavior does not make something
> 'not a bug'. I and countless other PHP devs simply avoid using these easily
> correctable, useful language features because they are cumbersome,
> unexpected and actively discouraged in the documentation itself; how the
> sum of these facts doesn't qualify as a bug is outside all but the
> narrowest, most bizarre definitions of 'bug' that exists in any software
> community.
>
> 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's another one of those bonkers changes. It changes behaviour of
> > already existing syntax. This sort of meddling with the language is
> > difficult to detect, and there is little value in fixing it. Don't
> > piss off users for purety.
>
> 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,
> against-recommendation code. This is not an argument for purity - I want a
> working-as-expected ternary syntax as a feature, right now it is an
> un-feature and is a caveat that must be documented - it is a wart. If the
> goal was purity, PHP wouldn't even make the list of languages I would
> consider.
>
> 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 didnt
> exist significantly in the PHP community in 2012, would be a good place to
> start. It would not even be outside the realm of possibility to do a bit of
> evangelism via Github issues if such cases are found so they can be fixed
> with a 1-year notice.
>
> 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.
>
> cheers,
>
> --
> Leon Sorokin
>
>
>
> On 12/13/2014 5:20 PM, Derick Rethans wrote:
>
>> On Sat, 13 Dec 2014, Leon Sorokin wrote:
>>
>>  I was wondering if 7.0 could be the version to fix the long-standing
>>> incorrect ternary associativity bug in PHP [1].
>>>
>>
>> It is not a bug, as the issue's status says: "Not a bug".
>>
>>  This seems especially worthy of reconsideration since the Null
>>> Coalesce RFC has been accepted and merged [2] with the correct
>>> associativity [3].
>>>
>>
>> It's another one of those bonkers changes. It changes behaviour of
>> already existing syntax. This sort of meddling with the language is
>> difficult to detect, and there is little value in fixing it. Don't piss
>> off users for purety.
>>
>> I suggest you read this too:
>> http://derickrethans.nl/bc-dont-be-evil.html
>>
>>  The major version change seems like the only time to get this done in
>>> PHP.
>>>
>>
>> Only time it is *allowed*; that doesn't it should be done.
>>
>> cheers,
>> Derick
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Ok I'm going to draft an RFC for this when I have a spare moment.  This is
exactly the sort of contentious issue that the RFC process was created to
help resolve.  We'll bring it to a vote and everyone will make their
arguments.  If 2/3 vote to change the behavior, that'll be that.  I respect
Derrick's position on this but I could not disagree with it more.

--Kris

--089e0139fc28c7f14c050a229f66--