Grow your CSS skills. Land your dream job.

The usage of === in PHP

  • # May 15, 2013 at 3:22 am

    @traq

    I think we were quite off-topic in that post, but I think the discussion is good =)

    So, to recap, the difference between `==` (or `!=`) and `===` (or `!==`) is that the second one also tests type, so for instance (to use your exact example):

    < ?php
    $i = 0;
    // == does type coercion. FALSE and 0 are equivalent…
    if ($i == false) { /* true! */ }
    // …but NOT identical.
    if ($i === false) { /* false! */ }

    // real-world example:
    $str = “ABCDEFG”;
    // you hate the letter “A”.
    // make sure $str DOES NOT HAVE the letter “A” in it!
    if (strpos($str,”A”) == false) {
    // this compares as TRUE, even though “A” is in the string!
    // this is because the *first* position in the string is position *0*.
    // 0 == false.
    }

    // same example, but using ===
    if (strpos($str,”A”) === false) {
    // this compares as FALSE, as expected.
    // 0 !== false.
    }

    So, outside of most people not being aware of the difference, are there any downsides to using `===`/`!==`?

    # May 15, 2013 at 3:35 am

    There are some down sides where integers such as `(8 === 08)` would return false but `( 7 === 07)` would return true.
    Which is due to integers beginning with 0 being interpreted as an octal.
    As with the `(8 === 08)` case `8 it would actually === 010`.
    Just a small caveat but can cause issues if not known about.

    __
    # May 15, 2013 at 3:39 am

    > So, outside of most people not being aware of the difference, are there any downsides to using `===`/`!==`?

    `==` is a leading cause of logical *(referring to the programmer’s logic, not the parser’s)* comparison errors. In most cases, using `===` yields the same (intended) result without the risk of any unintended consequences.

    Yes, there are certainly times when you *want* to do type coercion – maybe , for example:

    < ?php
    // say we asked the user, “what is 2 + 2?”
    // and they wrote “4″ in the answer box:
    $answer = $_POST;

    // we check it:
    if( $answer === 4 ){
    // however, HTTP POST values are always strings,
    // so this will not compare as TRUE.
    }

    // two solutions:
    // explicitly cast $answer as an integer
    if( (int)$answer === 4 ){
    // works perfectly
    // some people will tell you this is the *best* approach
    // (and they’re not wrong, really)
    }

    // …or, you can allow PHP to do type coercion on its own
    if( $answer == 4 ){
    // works just fine
    // easier for coding kiddies to understand
    }

    …however, in my experience (both in my own programming, and in helping others), the difficulties when this *doesn’t* work far outweigh any benefits gained when it *does* work. Especially since this sort of flaw can work as intended *most of the time* (i.e., it doesn’t *always* break things. Broken things should *always* break).

    *****
    > There are some down sides where integers such as (8 === 08) would return false but ( 7 === 07) would return true. Which is due to integers beginning with 0 being interpreted as an octal. As with the (8 === 08) case 8 it would actually === 010. Just a small caveat but can cause issues if not known about.
    @unasAquila

    In your example, `(7 == 07)` and `(7 === 07)` are both true (as is `(7 == ’07′)`, but not `(7 === ’07′)`), while `(8 == 08)` and `(8 === 08)` are both false. Decimal and octal numbers are both integers in PHP; just different ways of writing them. Using `==` or `===` isn’t the problem here, it’s writing `08` when you really meant `8`. But yes, it’s certainly one of those obscure, frustrating behaviors!

    # May 15, 2013 at 4:00 am

    I think that the example with `$_POST` and `$_GET` is the best to also drive home the point of “don’t trust the user”. By allowing for “lazy” type coercion, you might end up with slightly more risks in taking input from the user, but if you’re already forcing it to be an int when you’re expecting it to be an int, that should handle some of that.

    @unasAquila I’ve never actually used octals (or any kind of numbers outside of normal decimals). How would one go around that particular issue?

    # May 15, 2013 at 4:37 am

    in php i would do something like.

    $num = 08;
    $int = (int)ltrim($num, ’0′);

    Javascript however doesn’t seem to have the problem.

    # May 15, 2013 at 5:01 am

    No, that doesn’t appear to be working.

    Of course, looking closer at it, that’s because it appears to be set to 0 immediately. `8 == 08` also returns false, but `0 == 08` returns true. I’m very much leaning towards “it’s not a bug, it’s a feature” =) The moment you start an integer with 0, it treats it as an octal number.

    (on a sidenote, casting the string `08` to int does turn it into the decimal number 8)

    # May 15, 2013 at 5:09 am

    If you expect an int from user input, the input will probably be a string.

    $num = ’08′;
    $int = (int)ltrim($num, ’0′);

    > (on a sidenote, casting the string 08 to int does turn it into the decimal number 8)

    Seems a bit obsolete then :p

    # May 15, 2013 at 5:18 am

    @CrocoDillon Indeed! Since yeah, that’s really the only use case I can think of where what you have is something along the lines of `08` when what you really want is 8.

    My comment ended up a sidenote because I was experimenting and then suddenly noticed that. =)

    __
    # May 15, 2013 at 11:22 am

    > Of course, looking closer at it, that’s because it appears to be set to 0 immediately.

    That’s because octal (base **8**) uses the digits 0-7. `08` is invalid, and so produces `0`.

    @unasAquila, treating an octal number as a string won’t work as expected. Even though you typed `08`, PHP doesn’t store the number that way. This is not because `08` is invalid – try it with a valid octal number and you’ll see the same thing:

    < ?php
    print strval( 014 );
    // outputs “12″, not “014″

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".