Forums

  • # 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: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: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 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 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag