SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 34
  1. #1
    SitePoint Addict blizzman24's Avatar
    Join Date
    Jul 2004
    Location
    Texas
    Posts
    345
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    what is this operator?

    I tried searching on google, but for some reason searching "php ===" yields irrelevant results.

    in php, what does the '===' mean? how is it different from '=='?

  2. #2
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  3. #3
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by blizzman24 View Post
    I tried searching on google, but for some reason searching "php ===" yields irrelevant results.

    in php, what does the '===' mean? how is it different from '=='?
    For those who don't want to look things up the short answer is this - it is the strict comparison operator. There's also it's cousin !==.

    PHP is a loosely typed language. That is to say it will treat 3 and '3' the same depending on the context of the code. 90% of the time this is fine. Sometimes it's not because the computer is wrong on its guess. A key point is 0, null, false and '' all evaluate to false. However, what if you need to know if a function returned 0 as the result of a calculation, or false indicating the calculation couldn't be done?

    Enter the strict comparison operator which compares both the value and the underlying datatype. Hence $a === $b if and only if they have the same value and the same type.

    0 == false // This is true, the values are effectively the same in most contexts.
    0 === false // This is false. One is an integer and the other is Boolean.

    This problem comes up quite a bit in PHP because the older functions (strtotime, strpos) will return false on fail but can potentially return 0 as a value. If PHP was being written today the functions wouldn't return false at all, they'd throw an error which you're code could then catch. But throw/catch has only been around in PHP since version 5.

    This is one reason I seriously want Zend to consider taking all functions currently in PHP and putting them in a legacy namespace in PHP 6, then rebuilding the function library FROM SCRATCH. But that's an argument for another thread.

  4. #4
    PHP Guru lampcms.com's Avatar
    Join Date
    Jan 2009
    Posts
    921
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Adding my 2 cents: always use === when you want to use ==
    == is evil and can produce false matches.

    There are some situations that you should be aware about where using the === will cause false condition where you would expect a true, in which case use type juggling to convert argument to expected type
    My project: Open source Q&A
    (similar to StackOverflow)
    powered by php+MongoDB
    Source on github, collaborators welcome!

  5. #5
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    I disagree. If you don't like how PHP handles variables use another language - loose datatyping is one of the points of the language and with it the == operator. === should be reserved for when you need to check the value and the datatype together, which isn't that often.

  6. #6
    Floridiot joebert's Avatar
    Join Date
    Mar 2004
    Location
    Kenneth City, FL
    Posts
    823
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure if I ever use the strict equality operator for checking anything other than whether a core function returned a boolean false or an expected result.

  7. #7
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by joebert View Post
    I'm not sure if I ever use the strict equality operator for checking anything other than whether a core function returned a boolean false or an expected result.
    I use it to check whether some database fields hold 0 vs. null quite often (null meaning no response most often).

  8. #8
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    I use === all the time, which means that in the exceedingly few situations where it fails to work as expected, usually that's due to some assumption that I needed to know about in the first place.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  9. #9
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Location
    Molde, Norway
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lampcms.com View Post
    Adding my 2 cents: always use === when you want to use ==
    == is evil and can produce false matches.
    I totally agree here. Using == can cause an error in some rare situations, for instance when false is returned, but is interpreted as 0 or the other way around.

    The better practice in my point of view is to use Exceptions instead of having a function return two different datatypes.

    A function which job is to return a number, should not return false on error. If the function can't return an integer, then throw an Exception instead.
    Software developer at ADCom Data
    My blog for dumping information

  10. #10
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    To quote some recent 'Tweets' I had with another SP member...

    Quote Originally Posted by Anthony Sterling
    is seriously tempted to start a movement to get #php devs to use the === comparator by default. #debugging #sucks
    Quote Originally Posted by Paul Decowski
    Using identicality operator by default defeats the purpose of PHP being a dynamically typed language.
    Quote Originally Posted by Anthony Sterling
    I disagree Paul. I feel it should be a conscious act when you use a loose comparison, a great feature, but use it purposefully
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  11. #11
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    You epically fail to see the huge amount of confusion that would bring down on the newbs. For all it's uses, strong datatyping is a barrier to entry for new programmers. One of PHP's strengths is the ease of which it can be learned.

    PHP's default behavior with == is fine. Irksome sometimes, but more easily solved by having functions throw exceptions and return only one datatype (I'm looking at you strpos, fileread, strtotime and a host of others). It would also be nice to be able to declare strict variables that only accept one datatype, and tolerant variables that silently convert incoming data to their type alongside the current scalar variables that PHP uses.

    But making comparison be datatype sensitive while making variable declaration datatype agnostic will cause a hell of a lot more confusion than it solves - worse it will confuse the people least able to deal with confusion; the new programmers who don't know what a datatype is.

  12. #12
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    You epically fail to see the huge amount of confusion that would bring down on the newbs. For all it's uses, strong datatyping is a barrier to entry for new programmers. One of PHP's strengths is the ease of which it can be learned.
    I disagree. Strict rules weed out confusion. Loose rules create confusion (in beginners) but usually add benefit when comprehended. So, with strict rules (strong typing in this case) the learning curve is steeper, but there is less confusion.

    Quote Originally Posted by Michael Morris View Post
    PHP's default behavior with == is fine. Irksome sometimes, but more easily solved by having functions throw exceptions and return only one datatype (I'm looking at you strpos, fileread, strtotime and a host of others).
    But that's not the case.

    Quote Originally Posted by Michael Morris View Post
    It would also be nice to be able to declare strict variables that only accept one datatype, and tolerant variables that silently convert incoming data to their type alongside the current scalar variables that PHP uses.
    And neither is this.

    Quote Originally Posted by Michael Morris View Post
    But making comparison be datatype sensitive while making variable declaration datatype agnostic will cause a hell of a lot more confusion than it solves - worse it will confuse the people least able to deal with confusion; the new programmers who don't know what a datatype is.
    I sort of agree with this.

    Having said all that, let me quote my tweet again:

    Quote Originally Posted by Paul Decowski
    Using identicality operator by default defeats the purpose of PHP being a dynamically typed language.
    I still stand by this. Loose typing is a feature and defaulting to using strict comparison operators takes that feature away.

  13. #13
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by decowski View Post
    I still stand by this. Loose typing is a feature and defaulting to using strict comparison operators takes that feature away.
    Right, I'll get back to memorising this loose comparison table.

    http://www.php.net/manual/en/types.comparisons.php

    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  14. #14
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by decowski View Post
    I still stand by this. Loose typing is a feature and defaulting to using strict comparison operators takes that feature away.
    There is still no reason to NOT use === where the two are supposed to be the same type.

    Correct use of a language that allows loose typing means that you would be using both == and === depending on what types the fields being compared are allowed to be. If it wasn't appropriate to use === when the two are required to be the same type then there'd be no reason for === to exist.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  15. #15
    SitePoint Addict eanimator's Avatar
    Join Date
    Sep 2005
    Posts
    396
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    === is used to check for equal values and both values must have same types. hope this helps

  16. #16
    SitePoint Evangelist Dave Morton's Avatar
    Join Date
    Sep 2003
    Location
    Carson City, NV
    Posts
    557
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For myself:
    when I'm checking for non-empty strings, I use ==
    when I'm checking for non-zero numbers, I use ==
    in all other cases, I use ===, and I have no worries, other than the voices laughing at my pr0n collection.
    Making a difference, one little psychotic episode at a time
    Geek Cave Creations
    Beta testers needed for pChat
    Dave's Gallery

  17. #17
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    Right, I'll get back to memorising this loose comparison table.
    If you're memorising the table then, ekhm, you're doing it wrong.

  18. #18
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    There is still no reason to NOT use === where the two are supposed to be the same type.
    Of course. I didn't say there was. I said using it by default was wrong.

    In most cases you don't care about the type of a variable:

    PHP Code:
        if ($name == "Pawel") {
        
    // ...

        
    if ($price == 4.99) {
        
    // ... 
    There is a very limited number of cases when the datatype matters. That is, usually, when comparing a boolean to 0, an empty string or the string "0".

  19. #19
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by decowski View Post
    If you're memorising the table then, ekhm, you're doing it wrong.
    I was making a point, but having said that -

    why does "php" equal 0 and TRUE at the same time?

    ("php" == 0) is true
    ("php" == TRUE) is true
    (0 == TRUE) is false

    What other non-intuitive comparisons are hiding, waiting to take us unaware,
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  20. #20
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    I was making a point, but having said that -

    why does "php" equal 0 and TRUE at the same time?
    Because when comparing a string to an int, PHP casts the string into an int.

    • "php" is cast to 0
    • "123php" is cast to 123
    • "0" is cast to 0


    When comparing a string to a boolean it casts the string to a boolean.

    • "php" is cast to true
    • "" is cast to false
    • "0" is cast to false


    Unintuitive? Maybe. But what would be intuitive? Just learn the simple rules and stop making excuses.

  21. #21
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by decowski View Post
    Of course. I didn't say there was. I said using it by default was wrong.

    In most cases you don't care about the type of a variable:

    PHP Code:
        if ($name == "Pawel") {
        
    // ...

        
    if ($price == 4.99) {
        
    // ... 
    There is a very limited number of cases when the datatype matters. That is, usually, when comparing a boolean to 0, an empty string or the string "0".
    There are other cases too, which bode very badly for security.
    Code php:
    $price = true;
    if ($price == 4.99) {
        // pass
    }
    if ($price === 4.99) {
        // fail
    }

    Code php:
    $name = 0;
    if ($name == "Pawal") {
        // pass
    }
    if ($name === "Pawal") {
        // fail
    }
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  22. #22
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    There are other cases too, which bode very badly for security.
    Code php:
    $price = true;
    if ($price == 4.99) {
        // pass
    }
    if ($price === 4.99) {
        // fail
    }

    Code php:
    $name = 0;
    if ($name == "Pawal") {
        // pass
    }
    if ($name === "Pawal") {
        // fail
    }
    If you have to worry about a case like this then you have far more to worry about than comparison operators.

    You're introducing a logic bug in your code if you allow a price and name be booleans.

  23. #23
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by decowski View Post
    If you have to worry about a case like this then you have far more to worry about than comparison operators.

    You're introducing a logic bug in your code if you allow a price and name be booleans.
    $name was not a boolean, it was a number - which can be achieved without much difficulty when bad people want to break your code. Why do they want to break your code? You may have a pay wall, or sensitive data, or credit cards, or they may just be curious.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  24. #24
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,729
    Mentioned
    104 Post(s)
    Tagged
    4 Thread(s)
    As a simple example, I recall where forms were adjusted so that negative price values were sent to the payment system. The companies sure got some surprises here.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  25. #25
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    pmw57

    Are you here to be argumentative? You left another thread claiming you had to go to bed 2.5 hours ago. Looks like you didn't make it?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •