On 14 December 2014 at 08:24, Leon Sorokin <leeon...@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
