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 <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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
