6 ms·

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

quink 14y ago
A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea. F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."
- mparlane 14y ago
  I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes. What I don't get is that they are keen to modify php source. But not to just keep using the same php release? I agree with E, they take floats not strings apparently.
  - soulclap 14y ago
    Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.
    - Evbn 14y ago
      I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.
      - JaggedJax 14y ago
        I would almost guarantee security guidelines were the reason. He states they are dealing with tax data, and I would bet they handle some credit card data as well. If they even touch credit card data they have to be PCI compliant (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...) which requires specific versions of PHP.
        pilif 14y ago
        If it requires specific versions of PHP, I would hope that doesn't include a self-patched build that deliberately masks erroneous input data by treating NULL as 0 The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.
        alkavan 14y ago
        Where does it say in this page a specific version of PHP ? I searched for "PHP" and did not find anything.
  - pacmon 14y ago
    Reporter posted this: "...which is why we are moving to a supported, fairly-recent platform". I'm guessing it's the support their after.
- deleted 14y ago
  [deleted]
- TylerE 14y ago
  I disagree with point A. The old behavior makes a LOT more sense symbolically. I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..
  - steve8918 14y ago
    I don't agree with your analogy. The question is more similar to "Can you please tell me the number format of <silence>". How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0). In this case, NULL is definitely more appropriate, because the input is invalid.
    - phene 14y ago
      What's the numeric representation of the volume of <silence>? 0 dB
      - felipellrocha 14y ago
        I think you missed the point here. Steve's analogy asks for a number format, not a volume...
      - MBlume 14y ago
        Downvoted for cleverness.
      - dpark 14y ago
        So you make up a different question to fit the answer you want? Actually that seems about right for PHP.
      - mturmon 14y ago
        Since dB are a log scale, more properly, it would be -Inf dB.
        14y ago
- columbo 14y ago
  I disagree with (A). According to the php docs floatval('122.34343The') == 122.34343 floatval('BLARTLBARTFAST') == 0 Why should it take the input and choose a different response than what floatval would respond with? If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same. It's inconsistent behavior.
  - quink 14y ago
    > I disagree with (A). Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php http://www.php.net/manual/en/function.number-format.php
    - arde 14y ago
      Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.
steve8918 14y ago
I don't believe there should be any obligation for developers to maintain undefined behavior across versions. Even with defined behavior, sometimes APIs change, for legitimate reasons. The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.
lifthrasiir 14y ago
Regardless of the prior behavior, that particular behavior was not documented [1] and subject to change. I do think it is PHP's (very big) fault that the proper documentation on various edge cases is missing, but it is a bit too much to disallow PHP to change undocumented behaviors. That said, the proper documentation is not enough (and PHP does not get this right either); it's rather a mere prerequisite. [1] http://php.net/number-format http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.
- soulclap 14y ago
  Well, exactly. It doesn't say what happens, so pass floats or expect the unexpected. I get your point but I don't think I have ever seen documentation anywhere that covers all of the possible 'abuse' scenarios.
  - lifthrasiir 14y ago
    It is possible to add a catch-all clause to the documentation. For example any non-float argument is converted to float via floatval(), or raises an error, and so on. This behavior can be made consistent across every API so that the documentation has only one place to describe it. PHP is missing this either AFAIK.
    - soulclap 14y ago
      I agree this would be ideal. Will definitely keep this in mind when writing documentation (and code) for my own tiny open source projects. All the double and triple checking just adds so much bloat most of the time...
    - dpark 14y ago
      > This behavior can be made consistent across every API so that the documentation has only one place to describe it. Sounds like that's what 'zend_parse_parameters' does, actually.
- josegonzalez 14y ago

quink 14y ago

A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea. F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."

mparlane 14y ago
I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes. What I don't get is that they are keen to modify php source. But not to just keep using the same php release? I agree with E, they take floats not strings apparently.
- soulclap 14y ago
  Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.
  - Evbn 14y ago
    I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.
    - JaggedJax 14y ago
      I would almost guarantee security guidelines were the reason. He states they are dealing with tax data, and I would bet they handle some credit card data as well. If they even touch credit card data they have to be PCI compliant (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...) which requires specific versions of PHP.
      - pilif 14y ago
        If it requires specific versions of PHP, I would hope that doesn't include a self-patched build that deliberately masks erroneous input data by treating NULL as 0 The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.
      - alkavan 14y ago
        Where does it say in this page a specific version of PHP ? I searched for "PHP" and did not find anything.
- pacmon 14y ago
  Reporter posted this: "...which is why we are moving to a supported, fairly-recent platform". I'm guessing it's the support their after.
deleted 14y ago
[deleted]
TylerE 14y ago
I disagree with point A. The old behavior makes a LOT more sense symbolically. I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..
- steve8918 14y ago
  I don't agree with your analogy. The question is more similar to "Can you please tell me the number format of <silence>". How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0). In this case, NULL is definitely more appropriate, because the input is invalid.
  - phene 14y ago
    What's the numeric representation of the volume of <silence>? 0 dB
    - felipellrocha 14y ago
      I think you missed the point here. Steve's analogy asks for a number format, not a volume...
    - MBlume 14y ago
      Downvoted for cleverness.
    - dpark 14y ago
      So you make up a different question to fit the answer you want? Actually that seems about right for PHP.
    - mturmon 14y ago
      Since dB are a log scale, more properly, it would be -Inf dB.
      - 14y ago
columbo 14y ago
I disagree with (A). According to the php docs floatval('122.34343The') == 122.34343 floatval('BLARTLBARTFAST') == 0 Why should it take the input and choose a different response than what floatval would respond with? If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same. It's inconsistent behavior.
- quink 14y ago
  > I disagree with (A). Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php http://www.php.net/manual/en/function.number-format.php
  - arde 14y ago
    Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.

steve8918 14y ago

I don't believe there should be any obligation for developers to maintain undefined behavior across versions. Even with defined behavior, sometimes APIs change, for legitimate reasons. The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.

lifthrasiir 14y ago

Regardless of the prior behavior, that particular behavior was not documented [1] and subject to change. I do think it is PHP's (very big) fault that the proper documentation on various edge cases is missing, but it is a bit too much to disallow PHP to change undocumented behaviors. That said, the proper documentation is not enough (and PHP does not get this right either); it's rather a mere prerequisite. [1] http://php.net/number-format http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.

soulclap 14y ago
Well, exactly. It doesn't say what happens, so pass floats or expect the unexpected. I get your point but I don't think I have ever seen documentation anywhere that covers all of the possible 'abuse' scenarios.
- lifthrasiir 14y ago
  It is possible to add a catch-all clause to the documentation. For example any non-float argument is converted to float via floatval(), or raises an error, and so on. This behavior can be made consistent across every API so that the documentation has only one place to describe it. PHP is missing this either AFAIK.
  - soulclap 14y ago
    I agree this would be ideal. Will definitely keep this in mind when writing documentation (and code) for my own tiny open source projects. All the double and triple checking just adds so much bloat most of the time...
  - dpark 14y ago
    > This behavior can be made consistent across every API so that the documentation has only one place to describe it. Sounds like that's what 'zend_parse_parameters' does, actually.
josegonzalez 14y ago