Hi guys,
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1]. This seems especially
worthy of reconsideration since the Null Coalesce RFC has been accepted
and merged [2] with the correct associativity [3].
The major version change seems like the only time to get this done in PHP.
[1] https://bugs.php.net/bug.php?id=61915
[2] https://wiki.php.net/rfc/isset_ternary
[3] http://news.php.net/php.internals/79584
thanks,
--
Leon Sorokin
Hey Leon,
I was wondering if 7.0 could be the version to fix the long-standing incorrect ternary associativity bug in PHP [1]. This seems especially worthy of reconsideration since the Null Coalesce RFC has been accepted and merged [2] with the correct associativity [3].
The major version change seems like the only time to get this done in PHP.
I’d love to see this fixed. I would be surprised if any code relies on the current behaviour and doesn’t just use brackets, since it’s so unintuitive.
Thanks.
Andrea Faulds
http://ajf.me/
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1].
It is not a bug, as the issue's status says: "Not a bug".
This seems especially worthy of reconsideration since the Null
Coalesce RFC has been accepted and merged [2] with the correct
associativity [3].
It's another one of those bonkers changes. It changes behaviour of
already existing syntax. This sort of meddling with the language is
difficult to detect, and there is little value in fixing it. Don't piss
off users for purety.
I suggest you read this too:
http://derickrethans.nl/bc-dont-be-evil.html
The major version change seems like the only time to get this done in PHP.
Only time it is allowed; that doesn't it should be done.
cheers,
Derick
I wonder how many people use ternary operators in an associative context.
My suspicion is that little of those that do really intend PHP
associativity.
But it'd need quite a parser to detect the affected usage.
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating;
the utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind.
It is not a bug, as the issue's status says: "Not a bug".
I can understand why this would have been a 'wontfix' for versions
pre-7.0. However, major version changes are done primarily to fix these
kinds of inconsistencies - that and marketing - and yes they are
precisely that: bugs. Documentation of unexpected behavior does not make
something 'not a bug'. I and countless other PHP devs simply avoid using
these easily correctable, useful language features because they are
cumbersome, unexpected and actively discouraged in the documentation
itself; how the sum of these facts doesn't qualify as a bug is outside
all but the narrowest, most bizarre definitions of 'bug' that exists in
any software community.
The fact that it may break some code that is used somewhere despite
documentation recommending against it (pretty much deprecating it
already for years) is a terrible reason not to re-evaluate the situation
given the huge opportunity to correct this.
It's another one of those bonkers changes. It changes behaviour of
already existing syntax. This sort of meddling with the language is
difficult to detect, and there is little value in fixing it. Don't
piss off users for purety.
The only thing that's bonkers here is outright refusal to make trivially
breaking changes (in addition to numerous other breaking changes already
accepted) simply for the sake of not breaking some 0.00001% of outdated,
against-recommendation code. This is not an argument for purity - I want
a working-as-expected ternary syntax as a feature, right now it is an
un-feature and is a caveat that must be documented - it is a wart. If
the goal was purity, PHP wouldn't even make the list of languages I
would consider.
Rather than simply pointing to a 3-year-old close-reason, it would be
prudent to actually get statistics on how often this unexpected behavior
is relied upon in large, popular codebases. Packagist & Github, that
didnt exist significantly in the PHP community in 2012, would be a good
place to start. It would not even be outside the realm of possibility to
do a bit of evangelism via Github issues if such cases are found so they
can be fixed with a 1-year notice.
It's short responses like this and the continued reliance on arguments
posed in a different era/landscape that compel me to reconsider my
continued participation in the PHP community at all.
cheers,
--
Leon Sorokin
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1].It is not a bug, as the issue's status says: "Not a bug".
This seems especially worthy of reconsideration since the Null
Coalesce RFC has been accepted and merged [2] with the correct
associativity [3].It's another one of those bonkers changes. It changes behaviour of
already existing syntax. This sort of meddling with the language is
difficult to detect, and there is little value in fixing it. Don't piss
off users for purety.I suggest you read this too:
http://derickrethans.nl/bc-dont-be-evil.htmlThe major version change seems like the only time to get this done in PHP.
Only time it is allowed; that doesn't it should be done.
cheers,
Derick
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating; the
utterly ridiculousT_PAAMAYIM_NEKUDOTAYIMargument comes to mind.It is not a bug, as the issue's status says: "Not a bug".
I can understand why this would have been a 'wontfix' for versions
pre-7.0. However, major version changes are done primarily to fix these
kinds of inconsistencies - that and marketing - and yes they are precisely
that: bugs. Documentation of unexpected behavior does not make something
'not a bug'. I and countless other PHP devs simply avoid using these easily
correctable, useful language features because they are cumbersome,
unexpected and actively discouraged in the documentation itself; how the
sum of these facts doesn't qualify as a bug is outside all but the
narrowest, most bizarre definitions of 'bug' that exists in any software
community.The fact that it may break some code that is used somewhere despite
documentation recommending against it (pretty much deprecating it already
for years) is a terrible reason not to re-evaluate the situation given the
huge opportunity to correct this.It's another one of those bonkers changes. It changes behaviour of
already existing syntax. This sort of meddling with the language is
difficult to detect, and there is little value in fixing it. Don't
piss off users for purety.The only thing that's bonkers here is outright refusal to make trivially
breaking changes (in addition to numerous other breaking changes already
accepted) simply for the sake of not breaking some 0.00001% of outdated,
against-recommendation code. This is not an argument for purity - I want a
working-as-expected ternary syntax as a feature, right now it is an
un-feature and is a caveat that must be documented - it is a wart. If the
goal was purity, PHP wouldn't even make the list of languages I would
consider.Rather than simply pointing to a 3-year-old close-reason, it would be
prudent to actually get statistics on how often this unexpected behavior is
relied upon in large, popular codebases. Packagist & Github, that didnt
exist significantly in the PHP community in 2012, would be a good place to
start. It would not even be outside the realm of possibility to do a bit of
evangelism via Github issues if such cases are found so they can be fixed
with a 1-year notice.It's short responses like this and the continued reliance on arguments
posed in a different era/landscape that compel me to reconsider my
continued participation in the PHP community at all.cheers,
--
Leon SorokinI was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1].
It is not a bug, as the issue's status says: "Not a bug".
This seems especially worthy of reconsideration since the Null
Coalesce RFC has been accepted and merged [2] with the correct
associativity [3].It's another one of those bonkers changes. It changes behaviour of
already existing syntax. This sort of meddling with the language is
difficult to detect, and there is little value in fixing it. Don't piss
off users for purety.I suggest you read this too:
http://derickrethans.nl/bc-dont-be-evil.htmlThe major version change seems like the only time to get this done in
PHP.
Only time it is allowed; that doesn't it should be done.
cheers,
Derick--
Ok I'm going to draft an RFC for this when I have a spare moment. This is
exactly the sort of contentious issue that the RFC process was created to
help resolve. We'll bring it to a vote and everyone will make their
arguments. If 2/3 vote to change the behavior, that'll be that. I respect
Derrick's position on this but I could not disagree with it more.
--Kris
Respectfully,
PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating
[...]
Documentation of unexpected behavior does not make something 'not a bug'.
Whether or not this particular bug is fixable, I do agree with this:
"we're not going to fix this because it's hard / too late" is not the
same as "this is not a bug".
For instance, attempting to decrement a null value with the -- operator
results in null, even though incrementing with ++ will result in int(1),
and, even more bafflingly, using -= 1 will result in int(-1). This is
documented behaviour, but with no rationale other than "it's always been
that way". http://3v4l.org/bfsZ8 Apparently, this bug has been around
since (at least) PHP 3, but does that really mean we're never allowed to
fix it? At least the resolution to this report was "Won't Fix" rather
than "Not a Bug": https://bugs.php.net/bug.php?id=20548
Personally, I consider the non-evaluation of arguments to undeclared
constructors (see "Default constructors" RFC thread) to be another
example (an unfortunate consequence of a valid optimisation, resulting
in behaviour that nobody would have specified), although Stas disagrees.
As I mentioned in that other thread, one of the implications of saying
"it's not a bug" is to assert that it's part of the language to work a
particular way, and so should be specified and reproduced in other
implementations (from tests on 3v4l.org, HHVM carefully replicates the
null-- bug, but not the no-constructor lazy evaluation). Changing it
then implies changing the language specification, and other
implementations matching the appropriate version. If, on the other hand,
we accept certain things as bugs in the implementation, then other
implementations may diverge in behaviour anyway, and a new major version
released on php.net could (in a sort of philosophical way) be considered
a new implementation.
Now, the associativity of the ternary operator is presumably in the
language specification already, and belongs there, as it's such a basic
attribute of the operator. I'm also inclined to agree that the benefit
may not outweigh the cost of fixing it at this stage, but I do think
it's worth discussing.
--
Rowan Collins
[IMSoP]
Hi!
The fact that it may break some code that is used somewhere despite
documentation recommending against it (pretty much deprecating it
already for years) is a terrible reason not to re-evaluate the situation
given the huge opportunity to correct this.
It will break some code. There's no chance that somebody somewhere
doesn't use this. And the change would break it. Worse yet, he won't be
able to know about it until the customer complains about code logic
being broken.
The only thing that's bonkers here is outright refusal to make trivially
breaking changes (in addition to numerous other breaking changes already
accepted) simply for the sake of not breaking some 0.00001% of outdated,
There's not that many breaking changes accepted, and each of them had to
be substantiated. "We had other breaking changes" is not a
substantiation. For example, "most uses of associativity are wrong ones"
- is, but that makes the idea of un-associating it even better, since
unlike changing the associativity, it actually makes the problem obvious
and easy to fix. Alternatively, of course, we could make a tool that
detects this and alerts the user, but making it loud still sounds better.
And the breakage we are discussing is not "trivial" - it's a logic
change which makes code silently take different codepath without anybody
knowing. In the world of BC breaks, this is one of the most evil ones.
So we should avoid it as much as possible.
Rather than simply pointing to a 3-year-old close-reason, it would be
prudent to actually get statistics on how often this unexpected behavior
is relied upon in large, popular codebases. Packagist & Github, that
Usually the burden of proof lays on whoever proposes the change. Note
that a lot of code is not public, especially for languages like PHP that
is used for websites - meaning, there's little reason to publicize any
code but reusable library code. And the fact that the change would not
break a handful of popular libraries doesn't mean it won't break scores
of websites whose source you can not see, but which are way more
important for the people using them than some library they don't use.
Yes, I understand that this means very high burden on somebody proposing
BC-breaking change, and it makes the development more conservative. It
is a high burden convince people that this change is worth the risk of
breaking potentially unknown code with unknown consequences. I think,
however, it's better than actually suffering these consequences.
Consider that however ugly this particular wart is, people has been
living with it for almost 20 years, and it may be preferable for them to
have somewhat ugly code than having broken code.
It's short responses like this and the continued reliance on arguments
posed in a different era/landscape that compel me to reconsider my
continued participation in the PHP community at all.
Sorry, but arguing from "do this or that or I'm quitting" does not seem
a very strong argument to me. More drama does not help to evaluate the
merits of changing the associativity of ?:. I think everybody here
values the time of the volunteers that continue to contribute to the
project, but I think keeping the discussion on the technical merits
would be better.
Stas Malyshev
smalyshev@gmail.com
On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
The fact that it may break some code that is used somewhere despite
documentation recommending against it (pretty much deprecating it
already for years) is a terrible reason not to re-evaluate the situation
given the huge opportunity to correct this.It will break some code. There's no chance that somebody somewhere
doesn't use this. And the change would break it. Worse yet, he won't be
able to know about it until the customer complains about code logic
being broken.
On what basis are you making that claim with such certitude? In all my
years, I have yet to encounter a single, solitary case where someone's
actually relying on PHP's wonky, counter-intuitive, non-standard
associativity with the ternary operator. If such a one-in-a-billion
scripts does exist somewhere, it's likely some PHP 4 thing that hasn't been
touched in years.
The only thing that's bonkers here is outright refusal to make trivially
breaking changes (in addition to numerous other breaking changes already
accepted) simply for the sake of not breaking some 0.00001% of outdated,There's not that many breaking changes accepted, and each of them had to
be substantiated. "We had other breaking changes" is not a
substantiation. For example, "most uses of associativity are wrong ones"
- is, but that makes the idea of un-associating it even better, since
unlike changing the associativity, it actually makes the problem obvious
and easy to fix. Alternatively, of course, we could make a tool that
detects this and alerts the user, but making it loud still sounds better.
And the breakage we are discussing is not "trivial" - it's a logic
change which makes code silently take different codepath without anybody
knowing. In the world of BC breaks, this is one of the most evil ones.
So we should avoid it as much as possible.Rather than simply pointing to a 3-year-old close-reason, it would be
prudent to actually get statistics on how often this unexpected behavior
is relied upon in large, popular codebases. Packagist & Github, thatUsually the burden of proof lays on whoever proposes the change. Note
that a lot of code is not public, especially for languages like PHP that
is used for websites - meaning, there's little reason to publicize any
code but reusable library code. And the fact that the change would not
break a handful of popular libraries doesn't mean it won't break scores
of websites whose source you can not see, but which are way more
important for the people using them than some library they don't use.Yes, I understand that this means very high burden on somebody proposing
BC-breaking change, and it makes the development more conservative. It
is a high burden convince people that this change is worth the risk of
breaking potentially unknown code with unknown consequences. I think,
however, it's better than actually suffering these consequences.
Consider that however ugly this particular wart is, people has been
living with it for almost 20 years, and it may be preferable for them to
have somewhat ugly code than having broken code.
I don't think the "we've been sick so long we're used to it now" argument
is very compelling. Some BC is expected in major revisions; and,
historically, we have been WAY too conservative about that, in my view.
When there's a major version and there's a BC-breaking change that either
fixes something many people have been complaining about or improves the
language in some other way without losing its identity, it should be a go.
Major revisions are when changes like this are supposed to be made because,
otherwise, these problems remain forever. I don't think it's rational to
continue to ignore one of the most-requested fixes to PHP because one or
two people out there may be relying on the broken behavior-- and yes, it is
broken in the sense that it does not behave in the manner it's expected to
for a C-like syntax.
Didn't we talk about doing polls before? We should do a poll on this in
the PHP community and see who, if anyone, has any code anywhere that relies
on this confusingly counter-intuitive behavior. I would be amazed if even
one person answered yes to that. So rather than continuing to guess and
make unfounded assumptions, why don't we just ask them and settle the
question here and now?
--Kris
It's short responses like this and the continued reliance on arguments
posed in a different era/landscape that compel me to reconsider my
continued participation in the PHP community at all.Sorry, but arguing from "do this or that or I'm quitting" does not seem
a very strong argument to me. More drama does not help to evaluate the
merits of changing the associativity of ?:. I think everybody here
values the time of the volunteers that continue to contribute to the
project, but I think keeping the discussion on the technical merits
would be better.Stas Malyshev
smalyshev@gmail.com
There's not that many breaking changes accepted, and each of them had to
be substantiated. "We had other breaking changes" is not a
substantiation. For example, "most uses of associativity are wrong ones"
- is, but that makes the idea of un-associating it even better, since
unlike changing the associativity, it actually makes the problem obvious
and easy to fix. Alternatively, of course, we could make a tool that
detects this and alerts the user, but making it loud still sounds better.
And the breakage we are discussing is not "trivial" - it's a logic
change which makes code silently take different codepath without anybody
knowing. In the world of BC breaks, this is one of the most evil ones.
So we should avoid it as much as possible.
The justification for not making breaking changes always grows as a
function amount-of-code-in-the-wild which could possibly be relying on
bugs.
This situation results in a permanent conclusion of 'better-never' in
lieu of 'better-now-than-later'. In PHP-land, the implication then is
that this gridlock cannot be resolved even by major versions (IMO, one
of very few reasons for major versions to exist at all).
Usually the burden of proof lays on whoever proposes the change. Note
that a lot of code is not public, especially for languages like PHP that
is used for websites - meaning, there's little reason to publicize any
code but reusable library code. And the fact that the change would not
break a handful of popular libraries doesn't mean it won't break scores
of websites whose source you can not see, but which are way more
important for the people using them than some library they don't use.Yes, I understand that this means very high burden on somebody proposing
BC-breaking change, and it makes the development more conservative. It
is a high burden convince people that this change is worth the risk of
breaking potentially unknown code with unknown consequences.
Without telemetry, there is obviously no way of ever asserting that
something is ripe for removal or even deprecation. So this burden of
proof is unmeetable by definition.
--
Leon Sorokin
While I think long-term this would be a beneficial change I think in
the short term it's quite a hurdle. 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.
I definitely want to clean up the language, but I don't see the value
in this one. 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.
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
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_fixedIn 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--
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 unassociative 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
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 unassociative 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.
Hey George,
That sounds like a good approach, actually, although I'm not sure about later fixing the associativity. If we make it non-associative this does break things, but very loudly rather than changing code's behaviour. I think we should do this.
Thanks.
Andrea Faulds
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, December 14, 2014 2:26 PM
To: George Bond
Cc: PHP internals
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?On 14 Dec 2014, at 12:01, George Bond
happy.melon.wiki+gb@gmail.com 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 unassociative 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.Hey George,
That sounds like a good approach, actually, although I'm not sure about
later
fixing the associativity. If we make it non-associative this does break
things,
but very loudly rather than changing code's behaviour. I think we should
do
this.
Although my inclination would be not to change anything, I agree that if
we do decide to change it, George's idea is the best approach.
Zeev
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
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_fixedIn 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--
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 unassociative 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
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
5.4 is a good example of what we don't want to do with minor versions. It consisted of a messy list of "those bits of the abandoned 6 which didn't quite make it into 5.3".
If we want major features more often, we can have major releases more often. This figure of 10 years gets mentioned a lot, but with annual releases, it wouldn't be unreasonable to expect 8.0 by 2020 (a year after 7.4).
5.4 is a good example of what we don't want to do with minor versions. It consisted of a messy list of "those bits of the abandoned 6 which didn't quite make it into 5.3".
5.4 should have been '6' with a 5.4 that provided the very same buffer
that 5.7 is now envisaged to provide with PHP7. There is still a
substantial code base reliant on legacy features such as
register_globals which requires substantial work to move from 5.3 to 5.4
and it is stumbling blocks like these which are STILL holding up
adoption of later versions with ISP's.
Anything 'broken' in PHP7 must have a managed upgrade path helped by
warnings in 5.7, and I'd even go as far as to say that proposed patches
for things like this fix should include migration tools before being
merged! So both 5.7 and 7 are required to prevent a rerun of previous
chaos ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Some thoughts from user land…
On the concern of breaking code out there that relies on the current behavior, I strongly suspect far more code would be fixed if the ternary operator were changed to match what other languages do. I hate to admit it, but my own shop is a good example. We have a particular application that has thousands of business rules in the form of boolean expressions written using the ternary operator. When I took over the application, every one of them that was non-trivial (i.e., 95% of them) was wrong because the developers who wrote them didn’t understand how the operator works. It’s still a problem. If the operator were fixed in v7 — really fixed, not just made non-associative — all those rules would magically work; that alone would present a strong impetus for us to migrate that app.
And the problem isn’t restricted to “those” guys that worked on that application back in the dark ages. The folks working here now still struggle with ternary if they haven’t used it recently. They’ve had enough code flagged in reviews to know that it’s problematic, but the usual solution is to rewrite it with switch or if-else, or to go crazy with parentheses. Either way, their code won’t break if the operator is fixed.
I’ve also interviewed a lot of PHP developers, and I usually ask about the ternary operator. Depending on their experience level, my hope is that they either A) know all about it and can use it without fear, but are respectful of the confusion it can cause others, or B) they don’t really understand it, but they know it can bite them so that they’re careful if they encounter it or feel the need to use it. The vast majority of the time, however, I get C) they think they know all about it and have no fear of using it — but their understanding is completely wrong. This is across the board, all experience levels from junior guys with a year under their belts to senior guys with 10+ years.
So, it seems that very few PHP developers actually understand how the ternary operator works in PHP. And those that do, because they tend to rarely use it in nested form, usually either just avoid doing so even when it makes sense or uses parentheses to avoid having to think too hard. Either way, their code is probably safe, and even if it’s not, nested use of ternary is so rare in most code bases that a manual review is not too troublesome.
As for the vast majority of developers who don’t understand the operator: the code everyone here is so worried about breaking is largely written by these folks, and it’s already broken. Fixing the ternary operator now will only help most of this code, while making it non-associative will break the code in a different way while also breaking the code of those who do understand the operator. Fixing it now, or changing it now to fix it later - either way, working code that doesn’t rely on parentheses needs to be adjusted. Fortunately, the nested ternary is a rare beast (in most apps, anyway), but even so, most folks would like to do that review only once. And if it’s to adjust code to work more sanely, the way most other languages do it, well, it stings a lot less in that case.
So my opinion, as a manager of millions of lines of closed-source code that I know no one else will fix for me, is to make changes to the ternary operator just once, and make that change one that fixes it to fit most people’s expectations. That’s the path that would be most beneficial to me.
--
Bob Williams
SVP, Software Development
Newtek Business Services, Inc.
“The Small Business Authority”
http://www.thesba.com/
Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
I strongly suspect far more code would be fixed if the ternary operator were changed to match what other languages do.
I appreciate your support, but either I am not understanding you, or
your reasoning is unsound.
If you have 'incorrectly' functioning code today that results in passing
unit tests and a correctly functioning business. Then a sudden change to
the behavior of this code would necessarily result in failing unit tests
and an incorrectly functioning business.
The code may be 'fixed' from a semantic point of view, but the logic
would be broken from a required-output point of view relative to how it
was operating previously, regardless of whether it was understood or not
when it was written.
--
Leon Sorokin
I strongly suspect far more code would be fixed if the ternary operator were changed to match what other languages do.
If you have 'incorrectly' functioning code today that results in passing
unit tests and a correctly functioning business. Then a sudden change to
the behavior of this code would necessarily result in failing unit tests
and an incorrectly functioning business.
What world is this that you live in where every line of code that’s written is fully unit-tested, where functional bugs in large, highly complex applications are both obvious and immediately apparent? In my world, I’ve inherited millions of lines of legacy code written seemingly to defy the possibility of unit testing, where there are large chunks of code that may run once every several years, and where many types of logic bugs are simply undetectable unless a team of auditors on the business side is double-checking every result of the code. Sure, I also have a million or two lines of newer code that is heavily unit-tested, but even that code has bugs.
Given that we have this bug to begin with (and yes, it’s a bug), as well as many of the others that have worked their way into the PHP code base, it strikes me that PHP itself is written in my world, not yours. Hey, reality bites.
Also, code that is thoroughly unit-tested is not the code we need to worry about for the very reasons you espouse. If the ternary behavior is changed, the one or two bugs that may be introduced in every several hundred K LOC will become immediately apparent on first test-run and probably be fixed in 30 minutes or less. It’s the crappy code that we have to worry about, the code that’s broken and no one even knows about it. In these cases, I maintain, fixing ternary would only improve the code’s functioning.
-Bob
--
Bob Williams
SVP, Software Development
Newtek Business Services, Inc.
“The Small Business Authority”
http://www.thesba.com/
Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
What world is this that you live in where every line of code that’s written is fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
situation differently:
- Someone wrote this function:
function add_five_pct($num) {
return $num * 1.10;
}
-
This function was then used to calculate profit margin and display
retail prices on your site and business has been great! Unknowingly,
you've been making 2x what was intended with no ill effects! -
A new hire then went through this code on his own accord and decided,
'wait, this function is a bug!' and took it upon himself to fix it to
'$num * 1.05'.
Would you say the e-commerce site has been 'fixed' to work correctly?
Should the dev be praised for fixing the clearly broken function without
consulting anyone?
I cannot come up with a clearer explanation of how a 'silent' code fix
can foul up the bigger picture in non-beneficial ways. That's the
scenario that's being discussed here. The main point of contention is,
no one knows how much code exists in the wild that uses and relies on
this misbehavior. My argument is 'negligible', others say it's
'non-negligible'. And the whole comedy is, no one can actually provide
definitive numbers since nobody will ever know but a tiny portion of all
source code that is out there, so all arguments stem from 'meta'
evidence and personal experience.
--
Leon Sorokin
What world is this that you live in where every line of code that’s
written is fully unit-testedYou took my example too literally; forget the unit tests. Imagine the
situation differently:
- Someone wrote this function:
function add_five_pct($num) {
return $num * 1.10;
}
This function was then used to calculate profit margin and display
retail prices on your site and business has been great! Unknowingly, you've
been making 2x what was intended with no ill effects!A new hire then went through this code on his own accord and decided,
'wait, this function is a bug!' and took it upon himself to fix it to '$num
- 1.05'.
Would you say the e-commerce site has been 'fixed' to work correctly?
Should the dev be praised for fixing the clearly broken function without
consulting anyone?I cannot come up with a clearer explanation of how a 'silent' code fix can
foul up the bigger picture in non-beneficial ways. That's the scenario
that's being discussed here. The main point of contention is, no one knows
how much code exists in the wild that uses and relies on this misbehavior.
My argument is 'negligible', others say it's 'non-negligible'. And the
whole comedy is, no one can actually provide definitive numbers since
nobody will ever know but a tiny portion of all source code that is out
there, so all arguments stem from 'meta' evidence and personal experience.--
Leon Sorokin--
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric. If we use
a sufficiently diverse and representative sample, we should easily be able
to get accurate enough results to settle this question once and for all.
The only cost is effort.
--Kris
Hi!
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric.
If you do it in a professional way, with properly randomized samples,
controlled statistics, etc. Putting a form on the internet and counting
people who may have by chance stumbled upon it or were directed to it by
promoters of certain position doesn't do that.
If we use a sufficiently diverse and representative sample, we should easily be able
to get accurate enough results to settle this question once and for all.
If.
Stas Malyshev
smalyshev@gmail.com
Hi all,
On Tue, Dec 16, 2014 at 6:17 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric.If you do it in a professional way, with properly randomized samples,
controlled statistics, etc. Putting a form on the internet and counting
people who may have by chance stumbled upon it or were directed to it by
promoters of certain position doesn't do that.
Instead of polling people, how about provide a compatibility check script?
This would be easy with tokenizer, I suppose.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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 unassociative 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.
As long as this unassociativity turns it into a hard syntax error (ie,
"php -l" will catch it out), I am not against this.
cheers,
Derick
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 unassociative 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.As long as this unassociativity turns it into a hard syntax error (ie,
"php -l" will catch it out), I am not against this.
I'm with Derick. We either don't change the implicit associativity,
or we make ambiguous statements a parse error with a clear link to the
documentation explaining to add parens in order to make the
associativity explicit.
-Sara
Leon Sorokin wrote on 13/12/2014 22:45:
Hi guys,
I was wondering if 7.0 could be the version to fix the long-standing
incorrect ternary associativity bug in PHP [1]. This seems especially
worthy of reconsideration since the Null Coalesce RFC has been
accepted and merged [2] with the correct associativity [3].The major version change seems like the only time to get this done in
PHP.[1] https://bugs.php.net/bug.php?id=61915
[2] https://wiki.php.net/rfc/isset_ternary
[3] http://news.php.net/php.internals/79584thanks,
--
Leon Sorokin
Actually, thinking further on this, I'm not sure I've ever actually been
affected by the associativity of ?: one way or the other.
I have fallen foul of its precedence relative to concatenation, as in:
echo 'hello' . false ? ' world' : ' there' . '!';
http://3v4l.org/i7cSc
But I think this is the same in other languages, and not related to this
bug?
Regards,
Rowan Collins
[IMSoP]