7 ms·

The ridiculously terrible behavior of == is what makes me the saddest. http://www.php.net/manual/en/types.comparisons.php http://www.php.net/manual/en/types.co

• gergles 15y ago
  Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?
  • cag_ii 15y ago
    Because the string is first converted to an integer. "==" makes the comparison after converting types (see: Type Juggling in the docs) where "===" requires that the types be the same in order to be equal. Kind of weird the first time you see it, but it's a language design choice and does make sense once you understand it.
    • Zak 15y ago
      I think the reason people object to this behavior, even when they do understand it is that it makes the obvious default (==) dangerous. It's especially dangerous in the hands of the sort of non-experts for whom it's intended to make life easier.
      • wvenable 15y ago
        == really isn't that dangerous unless you use it dangerously. Comparing non-numeric strings to numbers is already odd.
    • jessedhillon 15y ago
      What doesn't make sense is the rationale for designing it this way.
    • jwatzman 15y ago
      But then it means that "==" is no longer transitive, which I see as very unnatural and confusing (even if the underlying reasoning sort-of makes sense).
  • jmathai 15y ago
    It doesn't make sense unless you understand how PHP works - at which point you'd use ===.
    • jessedhillon 15y ago
      > It doesn't make sense unless you understand how PHP works ... In other words: equality is not intuitive. Awesome! --- Let's take a look at "how PHP works": 0 == 08 // true! WTF, really? Well, let's just use the magical 'I-mean-actual-equality-not-some-other-kind-of-equality' operator: 0 === 08 // also true! (Sonofabitch/Facepalm) * Infinity Of all the areas of a language in which one could gain expertise in, I think testing equality should not be one of the more difficult to master. This is just stupid behavior. 08 is an invalid octal sequence, but no error is raised. You can't detect this condition unless you do your own pre-parsing before allowing PHP to try to parse it!
      • wvenable 15y ago
        I've been programming in PHP for a long time and I've never ever accidentally used an octal anywhere. Does such a non-problem really need this much attention?
        • jessedhillon 15y ago
          Perhaps you ask a user to enter the month of their CC expiration date, which is shown as 08/14 on their card. $v = validated_integer($user_input); // the user input 08 if($v == 0 || $v === 0) { // let's just be safe // the Wrong Thing happens } This is a contrived example, sure. But you've never checked to see if a user input the number 0? Or a non-zero, positive integer?
          • wvenable 15y ago
            I'm not sure what you expect to happen there but the following code always produces "Correct!": $user_input = '08'; $user_input = (integer)$user_input; if ($user_input == 8) echo 'Correct!'; if ($user_input == 0) echo 'Incorrect!'; If you take out the cast, the result is the same. If you change the numbers to '010' and 10 respectively, the result is also "Correct!". There is no weirdness.
  • deleted 15y ago
    [deleted]
  • tzs 15y ago
    It makes sense for the same reason it makes sense in Perl: use a string as a number and you get the number that is at the start of the string. E.g., "12" == 12, and "12php" == 12.
    • nickik 15y ago
      That does not make sence that just meens both languages suck.
    • lmz 15y ago
      But Perl has both "eq" and "==". PHP doesn't.
    • rjh29 15y ago
      Perl recognises that it is a bad practice. perl -we ' print "true\n" if "12" == "12php"' Argument "12php" isn't numeric in numeric eq (==) at -e line 1. true perl -w -e 'my $foo = "12php"; $foo = $foo + 1; print $foo, "\n";' Argument "12php" isn't numeric in addition (+) at -e line 1. 13 (an exception seems to be made for $foo++ though... that's Perl for you).
      • btilly 15y ago
        $foo++ isn't an exception. It has documented behavior on strings. That is sometimes very useful.
        • rjh29 15y ago
          I meant it's an exception because it does not throw a warning, even though you are treating a string as a number. (This is contrary to $foo = $foo + 1). The DWIM string auto-increment doesn't even kick in unless the variable matches /^[a-z]/i.
• qntm 15y ago
  Except when you're comparing objects! I want to make sure that object A and object B are instances of the same class. Also, I want to make sure that they are equal i.e. that every attribute is equal. Also, since I'm now used to always using === instead of == for such comparisons, I use === to make the comparison. I would think that == would perform an == comparison on every attribute, whereas === would perform an === comparison on every attribute. Nope! Using === actually verifies that the A and B are in fact references to the same object in memory, just like the "is" operator in Python. Got me again, PHP! How do I do my === comparison? Manually, that's how!
  • webignition 15y ago
    Object equality is non-trivial matter and subjective. Java delegates the consideration of object equality to Object.equals(), intended to be implemented by yourself as required. That PHP chooses not to try and provide a means of determining object equality is not a poor choice. Using the === operator to test whether two variables are references to the same object is then also not a poor choice.
• danudey 15y ago
  The way I've explained this (braindead) behaviour to people is that == is the 'equivalence' operator, and === is the 'equality' operator. This sort of 'well, close enough' behaviour has bitten me in the past as well. While writing a JSON bridge between an older PHP backend system and a newer Rails frontend, we kept getting exceptions on the Rails end. It turns out that the JSON library uses isnumeric() to determine if a value is a number or not - which makes sense, in some respects. The problem is that we had a parameter (the external vendor's product SKU) which was a string that, in some cases, consisted entirely of digits. On those few occasions, the JSON library would say 'Oh, this is a number' and encode it as such in the JSON. When Rails tried to unpack it, we got an exception because our Rails model was validating the data on the remote end and choked on getting an integer instead of a string. We ended up having to actually modify the JSON library we were using (everything else we tried either didn't work or had the same bug) to modify the check. Completely ridiculous.