Yet another



  •  I found a gem

    if($user == false || $user['admin'] == false)
    {
        Header("Location: ".$login_url);
    }

    the correction was

    $login_url = 'https://oursite.login.com/';
    if( ($user == null) || ($user === false || $user['admin'] == false))
    {
        Header("Location: ".$login_url);
    }



  • The only problem with the first one is the lack of $login_url.  $user will cast to null if it is false so the 2nd essentially evaluates the same.  What's ironic is that you actually have a few WTFs yourself.  It should read:

     

     if (!$user || !$user['admin']) 

     

    The comparisons to false are completely unnecessary as is your  == with null, your === with false and the nesting of the second condition.  Honestly, I'd say the "fix" is a bigger WTF than the first. 



  • So what happens to both of your solutions when $user = Array('not_a_field_called_admin'=>'any_value');

    Unless you always have Notices set to off or just ignore them like lazy bums.

    Notice: Undefined index: admin on line XX

    besides, a WTF is just For The Win backwards.



  • Eh, notices in PHP are pretty lame.  Seriously, if I have to check for a key every time I access an element in an array it kind of defeats the whole "dynamic" nature of the language.  It will still evaluate as false if the key isn't there and it's not like I'm trying to call methods on it, so there's no chance of fatal errors.  If you want to use notices, that's cool but I personally find them a complete waste of time. 



  •  Stupid question, but i couldn't find the answer anywhere:

    what's the difference between == and === ? 



  • @SEMI-HYBRID code said:

     Stupid question, but i couldn't find the answer anywhere:

    what's the difference between == and === ? 

     

     == is 'equal to'

     === is 'really equal to'

     heh.

    Seriously though, === :

    TRUE if $a is equal to $b, and they are of the same type. (introduced in PHP 4) 

    thx google



  • @alapalme said:

    thx google
     

    thx you.

    anyway, MY google didn't find anything. which one did you use? 



  • Your welcome!

    http://www.google.ca/search?hl=en&q=php+comparison+operators&btnG=Google+Search&meta=

    First result

    - Al



  • FYI, The same operator exists in javascript.



  • @darkmattar said:

    So what happens to both of your solutions when $user = Array('not_a_field_called_admin'=>'any_value');

    Unless you always have Notices set to off or just ignore them like lazy bums.

    Notice: Undefined index: admin on line XX

    besides, a WTF is just For The Win backwards.

    What the hex? Is there no short-circuiting in PHP?

    Rhetorical question... I checked and there is. It will complain about undefined variables, though.

    @dhromed said:

    FYI, The same operator exists in javascript.
    JavaScript returns a much saner true for ( '0' != '' )



  • Nevermind. I just turned on my brain.

    For the record, the correct way (as far as I can tell) would be:

    $login_url = 'https://oursite.login.com/';
    if( isset($user['admin']) )
    {
        Header("Location: ".$login_url);

    }


    Sorry for the double post. 



  • @Zecc said:

    JavaScript returns a much saner true for ( '0' != '' )

     

    It is very useful to have '0' == 0 because PHP deals with data from all sorts of data sources quite often and they don't all deal with types in the same way. One example is MySQL which likes to return everything as a string. For example, an integer id field from a MySQL row where the id is 1, php will evaluate the following: id == 1 will return true, id === 1 will return false, and id === '1' will return true.



  • @shakin said:

    For example, an integer id field from a MySQL row where the id is 1, php will evaluate the following: id == 1 will return true, id === 1 will return false, and id === '1' will return true.
    Just because MySQL is a WTF doesn't mean PHP should become a WTF itself to be more convenient.



  • I was talking about the string with a single zero being equal to an empy string, which is a bit different of what you are talking about.

    But I re-checked and I'm a bit stunned to verify that I was wrong, <font face="courier new,courier">"0" </font>does not equal <font face="courier new,courier">""</font> in PHP.

    <font face="courier new,courier">$zero = "0"; echo empty($zero) ? 'true' : 'false';</font> still prints out <font face="courier new,courier">true</font>, though.



  • @Zecc said:

    For the record, the correct way (as far as I can tell) would be:

    That doesn't work if admin is set to false, which is definitely not the expected behavior.  The best is probably just doing if (!$user['admin'])  as that will work if admin is false or undefined.  Doing it the way the OP did is just silly, though.



  • @Welbog said:

    @shakin said:

    For example, an integer id field from a MySQL row where the id is 1, php will evaluate the following: id == 1 will return true, id === 1 will return false, and id === '1' will return true.
    Just because MySQL is a WTF doesn't mean PHP should become a WTF itself to be more convenient.

    It's not just MySQL, but everything.  POST and GET vars are both strings but you might be passing ints.  PHP just keeps the programmer from worrying about the specific type of a variable.  For the most part, this has never caused me problems and I don't need the === operator.  99% of the times I use === it is due to some brain-dead return values from built-in PHP functions, like strpos.  See, a sane strpos would return the index where a substring started.  If the string wasn't found, it would return -1.  PHP for some reason returns false if the string isn't found which means you have to check with === because position 0 is == to false.  In practice this is rarely a hassle but it always makes me wonder what the fuck the PHP developers were thinking. 



  • @morbiuswilters said:

    @Zecc said:

    For the record, the correct way (as far as I can tell) would be:

    That doesn't work if admin is set to false, which is definitely not the expected behavior.  The best is probably just doing if (!$user['admin'])  as that will work if admin is false or undefined.  Doing it the way the OP did is just silly, though.

    I've always used:

    if(empty($arr['val']))

    empty() and isset() are the only two ways to operate on variables that may not have been defined without rasing a notice.

    It's also pretty readable, IMO. 

     

    From the docs:

    empty() is the opposite of (boolean) var, except that no warning is generated when the variable is not set.

     

    In other words, it does exactly what you recommend... without generating an error.

    Coding with notices off is definitely a bad idea, as somtimes a "variable not defined" notice actually matters (e.g. you typoed a variable name, etc.).

    If you're aware that a line will produce a notice sometimes, and don't want to do things the clean way, at the very least suppress errors on that specific line, e.g.

    $name = @$_POST['name']; 

     



  • @merreborn said:

    In other words, it does exactly what you recommend... without generating an error.

    Coding with notices off is definitely a bad idea, as somtimes a "variable not defined" notice actually matters (e.g. you typoed a variable name, etc.).

    If you're aware that a line will produce a notice sometimes, and don't want to do things the clean way, at the very least suppress errors on that specific line, e.g.

    $name = @$_POST['name']; 

    Wow, what a tremendous waste of time when you can just turn the goddamn notices off.  I also tend to not be so sloppy as to typo a variable and I do unit tests so those kind of issues would be uncovered anyway.  But if you like wasting your time with ridiculous checks, be my guest. 



  • What does $login_url do to a logged in user? It looks like we are sending logged in users who are not admins to login again, unless it detects this and sends them somewhere more sane... in which case that's an extra pointless bounce.



  • @morbiuswilters said:

    Wow, what a tremendous waste of time when you can just turn the goddamn notices off.  I also tend to not be so sloppy as to typo a variable and I do unit tests so those kind of issues would be uncovered anyway.  But if you like wasting your time with ridiculous checks, be my guest. 
    I take it you're a fan of ON ERROR RESUME NEXT as well.

     



  • @merreborn said:

    Coding with notices off is definitely a bad idea, as somtimes a "variable not defined" notice actually matters (e.g. you typoed a variable name, etc.).

    I prefer Perl's "X is used only once" warning.  I think in a lot of cases ([i]especially[/i] array keys) preventing warnings about undefined variable just leads to a lot of initialization clutter.

     @merreborn said:

    $name = @$_POST['name']; 

     I remember reading something about using error suppression slowing things down quite a bit.  Is this still true?


Log in to reply