what is this operator?

[blizzman24]

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 '=='?

[Shrapnel_N5]

here you go
http://php.net/manual/en/language.op...comparison.php

[Michael Morris]

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.

[lampcms.com]

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

[Michael Morris]

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.

[joebert]

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.

[Michael Morris]

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).

[paul_wilkins]

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.

[paalgg]

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.

[AnthonySterling]

To quote some recent 'Tweets' I had with another SP member...

is seriously tempted to start a movement to get #php devs to use the === comparator by default. #debugging #sucks

Using identicality operator by default defeats the purpose of PHP being a dynamically typed language.

I disagree Paul. I feel it should be a conscious act when you use a loose comparison, a great feature, but use it purposefully

[Michael Morris]

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.

[decowski]

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.

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.

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.

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:

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.

[paul_wilkins]

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

[felgall]

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.

[eanimator]

=== is used to check for equal values and both values must have same types. hope this helps

[Dave Morton]

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.

[decowski]

Right, I'll get back to memorising this loose comparison table.

If you're memorising the table then, ekhm, you're doing it wrong.

[decowski]

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:

    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".

[paul_wilkins]

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,

[decowski]

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.

[paul_wilkins]

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:

    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.

$price = true;
if ($price == 4.99) {
    // pass
}
if ($price === 4.99) {
    // fail
}

$name = 0;
if ($name == "Pawal") {
    // pass
}
if ($name === "Pawal") {
    // fail
}

[decowski]

There are other cases too, which bode very badly for security.

$price = true;
if ($price == 4.99) {
    // pass
}
if ($price === 4.99) {
    // fail
}

$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.

[paul_wilkins]

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.

[paul_wilkins]

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.

[hash]

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?