5 ms·

I can understand the rationale for coercing strings to numbers for an operation that is not valid on strings, but coercing strings to numbers just because it's

I can understand the rationale for coercing strings to numbers for an operation that is not valid on strings, but coercing strings to numbers just because it's possible is clearly a terrible idea. It's like they looked at JavaScript and decided that the == operator was just not hazardous enough.

nikic 14y ago
Please have a look at the comments by "jabakobob at gmail dot com" and myself ("nikic@php.net"). They explain why such behavior is actually good, in most cases.
- oconnore 14y ago
  Well, "why such behaviour is good" is stretching it. Maybe just "why such behaviour is"?
  - nikic 14y ago
    It may be a matter of taste, but I always considered this particular feature of == beneficial. In the normal case, it is what you need (in the context that most PHP applications deal with, namely communication over HTTP and with MySQL). What is shown here is just a rare edge case that you should not normally encounter. But I think that == has some other behaviors which are really detrimental. Like 0 == 'hallo world'. Sadly those can't be fixed due to backwards compatibility.
- ctdonath 14y ago
  Throwing away data without unavoidably good reason is BAD behavior. Period. We've got gigabytes of RAM and terabytes of storage to work with; don't throw away characters in a string just because they don't fit in a compact data type used only because there is a passing resemblance of one to the other. If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE.
  - nbpoole 14y ago
    > If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE. Then use === and do a type-strict comparison. <?php // Prints bool(true) var_dump('9223372036854775807' == '9223372036854775808'); // Prints bool(false) var_dump('9223372036854775807' ==='9223372036854775808');
    - ctdonath 14y ago
      Last week I spent 4 hours trying to find what turned out to be a missing = because C++ will not complain, but will behave very differently, when = is confused with ==. Now you want to add === to the mix? I'll stand by the axiom that throwing away data should NOT occur unless no other sensible option is available. If I'm comparing two literal strings, I shouldn't have to start with the obscure knowledge that a simple comparison will result in an aggressive attempt to perform two consecutive non-obvious type casts high risk of data loss. I'm reminded of the great Belkin router fiasco: wireless routers were shipped with the "hold muh beer" great idea that random web page requests would be redirected to Belkin ad pages. I don't buy Belkin products any more (and that was years ago now) because knowing they would go there broke the trust that they wouldn't. Ditto here: if PHP is going to go to great lengths to try to throw away critical data (hey, I'm storing those numbers as strings BECAUSE I need all the digits), then I can't trust that the language won't do other similarly stupid things. I'm working in an industry where such a cavalier attitude to data can cost MILLIONS of $$$ over one failure, and can't afford to use a language where such failures are systemic. That there exists a workaround is inadequate. </tangent> Fine. I could use ===. The problem remains that a fundamental axiom of the language design is that casting lossless to lossy data types, without direction or warning, is considered acceptable. Ya know, if PHP wants to convert my numeric strings to integers for comparison, fine ... IF it maintains precision and preserves all the data. I shouldn't have to know of and use other operators/functions to explicitly avoid a pathological pursuit of forgetfulness.
      - ajross 14y ago
        No offense, but it took you four hours to chase down a syntax error? If it survived long enough to see that kind of debugging effort, it was almost certainly dead code; seems like a unit test would have caught it before the first commit. And what compiler are you using? GCC certainly will issue warnings when the result of a = operator is used in a boolean context.
- extension 14y ago
  If == is supposed to be a numeric comparison and you are supposed to use strcmp for strings then why does == (sometimes) work on strings? Make it always coerce to a number, or die trying. Overloading it as numeric or string compare depending on what the string looks like is ridiculous. And BTW, things that work in most cases, but not all cases, are exactly where bugs come from.
  - MartinCron 14y ago
    things that work in most cases, but not all cases, are exactly where bugs come from If I didn't have such a low pain tolerance, I would get that tattooed on my body somewhere prominent.
- mikeash 14y ago
  If it's mildly good in most cases as you claim, and catastrophically bad in certain cases as seems clear, then overall it's not a net gain. This is what continually baffles me about PHP. There are plenty of bad languages out there, but PHP seems pretty much unique in having a community that actively resists any improvement and actively campaigns to keep the broken stuff around.

nikic 14y ago

Please have a look at the comments by "jabakobob at gmail dot com" and myself ("nikic@php.net"). They explain why such behavior is actually good, in most cases.

oconnore 14y ago
Well, "why such behaviour is good" is stretching it. Maybe just "why such behaviour is"?
- nikic 14y ago
  It may be a matter of taste, but I always considered this particular feature of == beneficial. In the normal case, it is what you need (in the context that most PHP applications deal with, namely communication over HTTP and with MySQL). What is shown here is just a rare edge case that you should not normally encounter. But I think that == has some other behaviors which are really detrimental. Like 0 == 'hallo world'. Sadly those can't be fixed due to backwards compatibility.
ctdonath 14y ago
Throwing away data without unavoidably good reason is BAD behavior. Period. We've got gigabytes of RAM and terabytes of storage to work with; don't throw away characters in a string just because they don't fit in a compact data type used only because there is a passing resemblance of one to the other. If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE.
- nbpoole 14y ago
  > If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE. Then use === and do a type-strict comparison. <?php // Prints bool(true) var_dump('9223372036854775807' == '9223372036854775808'); // Prints bool(false) var_dump('9223372036854775807' ==='9223372036854775808');
  - ctdonath 14y ago
    Last week I spent 4 hours trying to find what turned out to be a missing = because C++ will not complain, but will behave very differently, when = is confused with ==. Now you want to add === to the mix? I'll stand by the axiom that throwing away data should NOT occur unless no other sensible option is available. If I'm comparing two literal strings, I shouldn't have to start with the obscure knowledge that a simple comparison will result in an aggressive attempt to perform two consecutive non-obvious type casts high risk of data loss. I'm reminded of the great Belkin router fiasco: wireless routers were shipped with the "hold muh beer" great idea that random web page requests would be redirected to Belkin ad pages. I don't buy Belkin products any more (and that was years ago now) because knowing they would go there broke the trust that they wouldn't. Ditto here: if PHP is going to go to great lengths to try to throw away critical data (hey, I'm storing those numbers as strings BECAUSE I need all the digits), then I can't trust that the language won't do other similarly stupid things. I'm working in an industry where such a cavalier attitude to data can cost MILLIONS of $$$ over one failure, and can't afford to use a language where such failures are systemic. That there exists a workaround is inadequate. </tangent> Fine. I could use ===. The problem remains that a fundamental axiom of the language design is that casting lossless to lossy data types, without direction or warning, is considered acceptable. Ya know, if PHP wants to convert my numeric strings to integers for comparison, fine ... IF it maintains precision and preserves all the data. I shouldn't have to know of and use other operators/functions to explicitly avoid a pathological pursuit of forgetfulness.
    - ajross 14y ago
      No offense, but it took you four hours to chase down a syntax error? If it survived long enough to see that kind of debugging effort, it was almost certainly dead code; seems like a unit test would have caught it before the first commit. And what compiler are you using? GCC certainly will issue warnings when the result of a = operator is used in a boolean context.
extension 14y ago
If == is supposed to be a numeric comparison and you are supposed to use strcmp for strings then why does == (sometimes) work on strings? Make it always coerce to a number, or die trying. Overloading it as numeric or string compare depending on what the string looks like is ridiculous. And BTW, things that work in most cases, but not all cases, are exactly where bugs come from.
- MartinCron 14y ago
  things that work in most cases, but not all cases, are exactly where bugs come from If I didn't have such a low pain tolerance, I would get that tattooed on my body somewhere prominent.
mikeash 14y ago
If it's mildly good in most cases as you claim, and catastrophically bad in certain cases as seems clear, then overall it's not a net gain. This is what continually baffles me about PHP. There are plenty of bad languages out there, but PHP seems pretty much unique in having a community that actively resists any improvement and actively campaigns to keep the broken stuff around.