Re: Fix incorrect ternary '?' associativity for 7.0?
| From: | Leon Sorokin | Date: | Sun, 14 Dec 2014 17:31:52 +0000 |
| Subject: | Re: Fix incorrect ternary '?' associativity for 7.0? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-79636@lists.php.net to get a copy of this message | ||
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 <leeoniya@gmail.com> wrote:On 12/14/2014 12:51 AM, Levi Morrison wrote: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. --GWhile 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 allshould 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