Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79636 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39787 invoked from network); 14 Dec 2014 17:32:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Dec 2014 17:32:01 -0000 X-Host-Fingerprint: 24.12.158.105 unknown Received: from [24.12.158.105] ([24.12.158.105:8711] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/91-26365-F89CD845 for ; Sun, 14 Dec 2014 12:32:00 -0500 To: internals@lists.php.net,George Bond Message-ID: <548DC988.6030108@gmail.com> Date: Sun, 14 Dec 2014 11:31:52 -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: PHP internals References: <548D494B.8010901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 24.12.158.105 Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0? From: leeoniya@gmail.com (Leon Sorokin) This sounds like a reasonable compromise to me and infinitely better than doing nothing. However, if 7.0 complains loudly enough about this already quasi-deprecated pattern, then the incubation period for an eventual fix need not be that of a decade-out major version, but of a 7.x point release. Oddly, 5.4 is a good example of a much larger incompatibility changelog than the provisional one for 7.0: http://php.net/manual/en/migration54.incompatible.php -- Leon Sorokin On 12/14/2014 6:01 AM, George Bond wrote: > On 14 December 2014 at 08:24, Leon Sorokin 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 >