FAQ
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

Search Discussions

  • Andrea Faulds at Dec 13, 2014 at 11:03 pm
    Hey Leon,
    On 13 Dec 2014, at 22:45, Leon Sorokin wrote:

    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/
  • Derick Rethans at Dec 13, 2014 at 11:20 pm

    On Sat, 13 Dec 2014, Leon Sorokin wrote:

    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
  • Ángel González at Dec 14, 2014 at 12:44 am
    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.
  • Leon Sorokin at Dec 14, 2014 at 12:53 am
    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

    On 12/13/2014 5:20 PM, Derick Rethans wrote:
    On Sat, 13 Dec 2014, Leon Sorokin wrote:

    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
  • Kris Craig at Dec 14, 2014 at 12:58 am

    On Sat, Dec 13, 2014 at 4:53 PM, Leon Sorokin wrote:
    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


    On 12/13/2014 5:20 PM, Derick Rethans wrote:

    On Sat, 13 Dec 2014, Leon Sorokin wrote:

    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
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    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
  • Rowan Collins at Dec 14, 2014 at 4:11 am

    On 14/12/2014 00:53, Leon Sorokin wrote:
    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]
  • Stanislav Malyshev at Dec 15, 2014 at 8:11 pm
    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
    [email protected]
  • Kris Craig at Dec 15, 2014 at 9:17 pm

    On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev 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, 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.
    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
    [email protected]

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Leon Sorokin at Dec 15, 2014 at 10:13 pm

    On 12/15/2014 2:11 PM, Stanislav Malyshev wrote:

    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
  • Levi Morrison at Dec 14, 2014 at 6:51 am
    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.
  • Leon Sorokin at Dec 14, 2014 at 8:24 am

    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
  • George Bond at Dec 14, 2014 at 12:02 pm

    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
  • Andrea Faulds at Dec 14, 2014 at 12:26 pm

    On 14 Dec 2014, at 12:01, George Bond 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.
    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/
  • Zeev Suraski at Dec 14, 2014 at 1:06 pm

    -----Original Message-----
    From: Andrea Faulds
    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 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.
    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
  • Leon Sorokin at Dec 14, 2014 at 5:32 pm
    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
  • Rowan Collins at Dec 14, 2014 at 7:49 pm

    On 14 December 2014 17:31:52 GMT, Leon Sorokin wrote:
    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).
  • Lester Caine at Dec 14, 2014 at 8:10 pm

    On 14/12/14 19:48, Rowan Collins wrote:
    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
  • Robert Williams at Dec 15, 2014 at 4:45 am
    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).
  • Leon Sorokin at Dec 15, 2014 at 6:51 am

    On 12/14/2014 10:45 PM, Robert Williams wrote:

    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
  • Robert Williams at Dec 15, 2014 at 5:59 pm

    On Dec 14, 2014, at 23:50, Leon Sorokin wrote:
    On 12/14/2014 10:45 PM, Robert Williams wrote:

    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).
  • Leon Sorokin at Dec 16, 2014 at 4:19 am

    On 12/15/2014 11:59 AM, Robert Williams wrote:
    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:

    1. Someone wrote this function:

    function add_five_pct($num) {
        return $num * 1.10;
    }

    2. 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!

    3. 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
  • Kris Craig at Dec 16, 2014 at 5:50 am

    On Mon, Dec 15, 2014 at 8:19 PM, Leon Sorokin wrote:
    On 12/15/2014 11:59 AM, Robert Williams wrote:

    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:

    1. Someone wrote this function:

    function add_five_pct($num) {
    return $num * 1.10;
    }

    2. 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!

    3. 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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    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
  • Stanislav Malyshev at Dec 16, 2014 at 9:17 am
    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
    [email protected]
  • Yasuo Ohgaki at Dec 16, 2014 at 9:48 am
    Hi all,
    On Tue, Dec 16, 2014 at 6:17 PM, Stanislav Malyshev 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
    [email protected]
  • Alain Williams at Dec 16, 2014 at 10:09 am

    On Tue, Dec 16, 2014 at 06:48:14PM +0900, Yasuo Ohgaki wrote:

    Instead of polling people, how about provide a compatibility check script?
    This would be easy with tokenizer, I suppose.
    +1

    --
    Alain Williams
    Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
    +44 (0) 787 668 0256 http://www.phcomp.co.uk/
    Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
    #include <std_disclaimer.h>
  • Derick Rethans at Dec 15, 2014 at 4:57 pm

    On Sun, 14 Dec 2014, George Bond 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.
    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
  • Sara Golemon at Dec 16, 2014 at 8:30 am

    On Mon, Dec 15, 2014 at 8:56 AM, Derick Rethans wrote:
    On Sun, 14 Dec 2014, George Bond 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.
    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
  • Rowan Collins at Dec 15, 2014 at 6:55 pm

    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/79584

    thanks,

    --
    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]

Related Discussions

People

Translate

site design / logo © 2023 Grokbase