7 ms·

You could use strcmp like you're supposed to I suppose, or ===.

by kcbanner 15y ago

ctdonath 15y ago
The language could not throw away data on an obscure whim.
- jasonlotito 15y ago
  It does not throw it away on an obscure whim. It's clearly documented, and well known. === is pretty much the standard. Your lack of knowledge does not make it obscure.
  - whateverer 15y ago
    > It does not throw it away on an obscure whim. So you could have predicted this yesterday? Just because it's codified somewhere, it doesn't make it clear, or anything other than a whim, or a product of circumstances, at best. That's not how languages should be defined, even if PHP clearly demonstrates that they can end up that way by chance. Rasmus' lack of foresight does not make it reasonable.
    - Groxx 15y ago
      Yes, you could have predicted this yesterday. In fact, this behavior has been documented explicitly for a year and a half: http://web.archive.org/web/20100808122711/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20100808122711/http://www.php.net... Earlier versions have said the comparison converts the numbers to integers though, which may be incorrect, and misleading if it was. Did PHP not convert float-like strings to floats in, eg, 2009? http://web.archive.org/web/20091024233139/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20091024233139/http://www.php.net...
      - whateverer 15y ago
        Why, it does indeed say, a link or two down from there, that strings will be coerced to float: http://web.archive.org/web/20091024234517/http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion http://web.archive.org/web/20091024234517/http://www.php.net... The point, however, is that you shouldn't pepper your language with operations which have consequences as hard to foresee as this with no good reason, and I really don't think that saving yourself some type conversions here and there would do.
        Groxx 15y ago
        "no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market. The same kind of logic is used to make `false == ""` true. Or any 'falsy' language. If you want strictly typed behavior, yes, it's stupid to do that. If you don't, then it makes some things simpler, at the expense of more edge cases that are unlikely to happen - note that this bug was reported in 2011, and people are acting like it's a new thing. Because it comes up so rarely that, while it technically exists, many people never encounter it.
        whateverer 15y ago
        > "no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market. You are right, in a way. Sure, it may attract and retain more newcomers, but that's like saying that tobacco is "teenager friendly". I think it's not beginner friendly at all if you must have years of experience to avoid the innumerable pitfalls which PHP lays for you all over the place, learning, e.g. the range of Integers in PHP, which defines when a string will be either a float or an int, or that you should actually use strcmp. In Python, Ruby, or heck, Haskell, you'd just have to do == and there would be no surprises.
    - jasonlotito 15y ago
      You've never used floats, have you?
      - whateverer 15y ago
        Yes, I have, thank you. How's the health? Oh, and "everyone knows that PHP lights the upper-rightmost pixel in you screen purple and will crash if there's no screen" would not, in fact, justify such a thing.
        jasonlotito 15y ago
        > Yes, I have, thank you. You must hate programming then. 9223372036854775807.0 == 9223372036854775808
        whateverer 15y ago
        Alright, I'll spell it out for you: the behaviour may be what you'd expect from floating-point comparisons, but it doesn't have to be a floating point comparison in the first place.
        jasonlotito 15y ago
        No, it doesn't. Language designers make lots of decisions that end up being silly. But they make them. In PHP, if it looks like a number, it will get treated like a number when being compared via ==. It's a simple, well-established, fundamental rule.
  - FuzzyDunlop 15y ago
    Sadly, while '===' is the quick fix, you then have to litter your code with type casting operators if you're comparing numbers, particularly those sourced from, say, a database, where everything is returned as a string. Or from GET or POST data, where everything is a string. This tripped me up when I was trying to compare two numbers, one of which was the result of a COUNT query via PDO. Of course, that COUNT result was a string. I suppose if you worked entirely with strings it's alright. Or it wouldn't be so bad if you could make the reasonable assumption that functions returned appropriately typed data.
- zeru 15y ago
  It does what it's intended to do. Use the methods you are supposed to use. You're just arguing for the sake of arguing now, or you just don't know what you are talking about at all.

You could use strcmp like you're supposed to I suppose, or ===.

ctdonath 15y ago

The language could not throw away data on an obscure whim.

jasonlotito 15y ago
It does not throw it away on an obscure whim. It's clearly documented, and well known. === is pretty much the standard. Your lack of knowledge does not make it obscure.
- whateverer 15y ago
  > It does not throw it away on an obscure whim. So you could have predicted this yesterday? Just because it's codified somewhere, it doesn't make it clear, or anything other than a whim, or a product of circumstances, at best. That's not how languages should be defined, even if PHP clearly demonstrates that they can end up that way by chance. Rasmus' lack of foresight does not make it reasonable.
  - Groxx 15y ago
    Yes, you could have predicted this yesterday. In fact, this behavior has been documented explicitly for a year and a half: http://web.archive.org/web/20100808122711/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20100808122711/http://www.php.net... Earlier versions have said the comparison converts the numbers to integers though, which may be incorrect, and misleading if it was. Did PHP not convert float-like strings to floats in, eg, 2009? http://web.archive.org/web/20091024233139/http://www.php.net/manual/en/language.operators.comparison.php http://web.archive.org/web/20091024233139/http://www.php.net...
    - whateverer 15y ago
      Why, it does indeed say, a link or two down from there, that strings will be coerced to float: http://web.archive.org/web/20091024234517/http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion http://web.archive.org/web/20091024234517/http://www.php.net... The point, however, is that you shouldn't pepper your language with operations which have consequences as hard to foresee as this with no good reason, and I really don't think that saving yourself some type conversions here and there would do.
      - Groxx 15y ago
        "no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market. The same kind of logic is used to make `false == ""` true. Or any 'falsy' language. If you want strictly typed behavior, yes, it's stupid to do that. If you don't, then it makes some things simpler, at the expense of more edge cases that are unlikely to happen - note that this bug was reported in 2011, and people are acting like it's a new thing. Because it comes up so rarely that, while it technically exists, many people never encounter it.
        whateverer 15y ago
        > "no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market. You are right, in a way. Sure, it may attract and retain more newcomers, but that's like saying that tobacco is "teenager friendly". I think it's not beginner friendly at all if you must have years of experience to avoid the innumerable pitfalls which PHP lays for you all over the place, learning, e.g. the range of Integers in PHP, which defines when a string will be either a float or an int, or that you should actually use strcmp. In Python, Ruby, or heck, Haskell, you'd just have to do == and there would be no surprises.
  - jasonlotito 15y ago
    You've never used floats, have you?
    - whateverer 15y ago
      Yes, I have, thank you. How's the health? Oh, and "everyone knows that PHP lights the upper-rightmost pixel in you screen purple and will crash if there's no screen" would not, in fact, justify such a thing.
      - jasonlotito 15y ago
        > Yes, I have, thank you. You must hate programming then. 9223372036854775807.0 == 9223372036854775808
        whateverer 15y ago
        Alright, I'll spell it out for you: the behaviour may be what you'd expect from floating-point comparisons, but it doesn't have to be a floating point comparison in the first place.
        jasonlotito 15y ago
        No, it doesn't. Language designers make lots of decisions that end up being silly. But they make them. In PHP, if it looks like a number, it will get treated like a number when being compared via ==. It's a simple, well-established, fundamental rule.
- FuzzyDunlop 15y ago
  Sadly, while '===' is the quick fix, you then have to litter your code with type casting operators if you're comparing numbers, particularly those sourced from, say, a database, where everything is returned as a string. Or from GET or POST data, where everything is a string. This tripped me up when I was trying to compare two numbers, one of which was the result of a COUNT query via PDO. Of course, that COUNT result was a string. I suppose if you worked entirely with strings it's alright. Or it wouldn't be so bad if you could make the reasonable assumption that functions returned appropriately typed data.
zeru 15y ago
It does what it's intended to do. Use the methods you are supposed to use. You're just arguing for the sake of arguing now, or you just don't know what you are talking about at all.