Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
Sender: happy.melon.wiki@gmail.com
In-Reply-To: <548D494B.8010901@gmail.com>
References: <B6.00.14066.691CC845@pb1.pair.com> <alpine.DEB.2.11.1412132316440.4080@whisky.home.derickrethans.nl>
 <CAFMT4NpeOuZyHk24iwSV866qXjnRg0z3Y35GX+e+PYEuXZHpmQ@mail.gmail.com> <548D494B.8010901@gmail.com>
Date: Sun, 14 Dec 2014 12:01:50 +0000
Message-ID: <CAFKLSKBh+yjXoBSqR9bpmi1tUfsOWNMj1QLZR5Hqz2A+R1mvzA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160b7ce527855050a2be52b
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
From: happy.melon.wiki+gb@gmail.com (George Bond)

--089e0160b7ce527855050a2be52b
Content-Type: text/plain; charset=UTF-8

On 14 December 2014 at 08:24, Leon Sorokin <leeoniya@gmail.com> wrote:
>
> On 12/14/2014 12:51 AM, Levi Morrison wrote:
>
> > While I think long-term this would be a beneficial change I think in
> > the short term it's quite a hurdle.
>
> This discussion will be identical whether we wait till PHP7 or PHP9 in a
> decade. The longer this change takes to make, the more code that will be
> mis-written to rely on the current behavior. If any long-term benefit is to
> be reaped, now is the best time to do it - every future major version will
> have a harder justification to make.
>
> > There is definitely code out there relying on this behavior and
> > changing it will result in the worst BC case: it will not fail in any
> > way but will instead act differently.
>
> There are also definitely IE5.5 users out there and websites that rely on
> IE5.5-only features, but the actual numbers matter. There's no doubt that
> somebody, somewhere is going to have broken code because they wrote it
> without reading the docs that recommend against it or without understanding
> how it works, or upgraded without reading a migration guide or realizing
> that major version upgrades do make breaking changes (more often than not).
> These people do exist and they may curse PHP rather than themselves and
> leave it forever; the desire of the core team to retain the maximum amount
> of these users is puzzling. The change under discussion will not be causing
> any sort of mass-exodus from PHP, the ecosystem will not collapse and it
> will not be the heat-death of the universe. It will be removing a
> long-discouraged behavior and bring expected uniformity to a common
> construct that has differed for no good reason from other languages.
>
> There's plenty of room for a #5 on the already non-0 list:
> https://wiki.php.net/phpng#incompatibilities_made_on_
> purpose_and_are_not_going_to_be_fixed
>
>  In my opinion, chaining or nesting ternaries at all
>> should be discouraged; changing the associativity doesn't change the
>> fact that they are more difficult to follow and more error prone than
>> using different constructs.
>>
>
> I would disagree on this point. Just like there are cases where a large
> switch/case results in more readable if-elseif chains, long conditional
> assignment chains can serve the same purpose, granted you space them
> appropriately. I would even go as far as saying that with proper spacing,
> they are more readable than the 'if' or 'case' blocks that would need to
> replace them.
>
> --
> Leon Sorokin
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
If you wanted an upgrade path that was not Evil (in the sense of not
introducing subtle and hard-to-diagnose bugs), could you not change the
operator to be *un*associative in PHP7?  That would effectively just make
concrete the discouragement/deprecation that's already in the
documentation, and would produce irritating but very visible errors for
anyone still actually using this functionality, as well as making them
alter their code in a forward-compatible way.  Then if you want to think
really long term, plan to implement the 'correct' associativity in the
*next* major version.

--G

--089e0160b7ce527855050a2be52b--