It's quite logical...

<?php
$a
= 0;
$b = 'x';
var_dump(FALSE == $a);
var_dump($a == $b);
var_dump($b == TRUE);
?>

This results in
bool(true)
bool(true)
bool(true)

if you were to follow simple rules learned in elementary school (or just common sense) then seemingly FALSE == TRUE. Opsie.

Of course, the PHP == operator, despite appearances is not an equivalence relation. The above shows exactly that. There is a complex set of rules on how comparisons are done. In our case, when comparing to bools, both values are casted to bool and those values are compared. When comparing a number to a string, the string is converted into a number and then two numbers are compared. These comparisons, as shown can be very different.

Comments

Manuals

When i started learning PHP 3 years ago this got me crazy too.
Since i was a C programmer, some weird bugs used to happen when i used == for comparisons. So, i decided to read the manuals...
Then, everything got explained...
At that time, i had the idea that all programming languages had the same base operations, (like = attributing a value), but they dont!

Programming languages may look like, but each one of them have a set of rules.
Your post is an example.
PHP have 2 diferent ways of comparisons, the == and the ===.
And if you dont study your selected languages rule's, you will think it's a crappy language because your programs doesn't work well.

Well, may be PHP is a crappy language, may be not =P

I think you misunderstand...

It's not saying that PHP is a crappy language. It's saying that PHP's casting behavior leads to some odd inconsistencies that are simply not what you expect.

I didint =D

I didint misunderstood =P
if my text seems it, sorry my poor english =P
it's been a long time i hasnt writting a single line in english.

PHP isnt a crappy language.
Im using it for 3 years, and i have no complains.

Crappyness

PHP is a crappy language. The fact you have no complains about it only shows you either know nothing better or have low standards,

I'd argue that programmers

I'd argue that programmers relying on how they "expect" a language to act when they haven't taken the time to learn it is The Real WTF here.

It's actually not a stretch to expect a language to act like the docs say the language will act. Nowhere does it say that == is sufficient for all logical tests. it does however explicitly say that "0" == 1 (as does any string). In any case, this is what Unit Testing helps you avoid in any language - programming based on assumptions and expectations instead of reality.

What? Are you serious?

This whole thing is the result of you not knowing your basic operators and type casts. Every single one of those ceases to be true when you use strong comparison instead of weak comparison.

It's unfortunate that you're flaunting your lack of knowledge of quite literally the very simplest parts of the language as "php annoyances."

PHP == insanity

Why should language need a === operator in the first place?

== can be taken to mean "sorta, kinda equals, but maybe not"

=== means "no, no, no... REALLY, REALLY equals, not sorta equals"

How many people with decent programming backgrounds write their first PHP script and then have to replace == with === ?

The point is that PHP breaks standard programming paradigms, and for the worse IMO.

=== is needed in any language

=== is needed in any language that is dynamically typed.

People with "decent programming backgrounds" know the difference between dynamic and static typing.

knowing v. doing

Knowing the difference means knowing to use (int) on one side of == to explicitly cast.

Some languages will automatically infer type + value comparison so 'x' == 0 is not true where (int) 'x' == 0 is true.

If you step back from arguing the point on technical merit and think about "what does the user intend", then one would expect 'x' == 0 to be false unless explicitly telling the interpreter to do otherwise.

nom nom nom

"=== is needed in any

"=== is needed in any language that is dynamically typed."

Such an operator might be convenient, but it does not seem necessary. There are dynamic languages that get by fine without it, e.g Lua.

It's only needed in PHP

It's only needed in PHP because PHP converts in the wrong direction. If it converted ints to bools to strings for comparison, none of this strangeness would be visible.

Why?

I've been using Python for a whole lotta years, and I've never missed the triple-equal operator.

>>> True === True
File "", line 1
True === True
^
SyntaxError: invalid syntax

In Python...

"===" is spelled "is".

>>> 5 == 5.0

True

>>> 5 is 5.0

False

dynamic languages

for example, perl doesn't need === operator as it has operators which force desired casting

4 eq "4" # true (string comparison)
4 == "4" # true (int comparison)

It's not that hard...

== compares value
=== compares value and type

Both of those are useful operations.

plus....

=== is also necessary when you are comparing strings that are very long numbers - like a GSM cell phone's SIM card number (which is where I ran into it). For example:

echo var_dump( ("11111111111111111111"=="11111111111111111112") )."\n";
echo var_dump( ("11111111111111111111"==="11111111111111111112") ) ."\n";

will give you

bool(true)

bool(false)

I think it just happens on strings over 20 chars, but that may be based on some setting. As soon as you put a non-number in there, that stops happening.

If it's not that hard, please

If it's not that hard, please explain how the 0 value equals "x". :)

Because the string 'x' is

Because the string 'x' is converted to an integer.

<?php
$x
= 'x';
$y = (int) $x;
var_dump($y);
?>

Output:
int(0)

You're right, that makes

You're right, that makes perfect sense!

Except no it doesn't, it's fucking stupid.

PHP is C based

C traditionally used atoi
atoi("x") is 0 ergo : atoi("x") === 0

http://en.wikipedia.org/wiki/Atoi

The str argument is a string, represented by an array of characters, containing the characters of a signed integer number. The string must be null-terminated. When atoi encounters a string with no numerical sequence, it returns zero (0). If the string holds a valid sequence of digits that represents the number 0, it also returns a 0, making it impossible to tell from the return value alone whether the string holds a valid number or not. The newer function strtol does not have this deficiency.

You're right, most of the

You're right, most of the comparisons don't make any sense.

Here's a list of the expected results for most comparisons:

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

Atleast the expected results are documented, even if they don't make sense.

even casting won't help you!

<?php
$a
= (string) 'x';
$b = (int) 0;
var_dump((int) $a === $b);
var_dump($a === (string) $b);
?>
.
Output:
bool(true);
bool(false);

so... there is a difference between $a and $b... or is there... *sigh*

It's based on how PHP

It's based on how PHP converts types.

Converting (int) 0 to a string just wraps the number in quotes, so (int)0 becomes (string)"0"

and "0" is not equal to "x"

Converting (string) "x" to an int, the way php does it is by searching the beginning of the string for numerals, it then takes as many of the numerals it finds (until it hits a non-number) and converts that into an integer. If there are no numbers at the beginning of the string, it defaults to (int)0.

therefore, 0 and 0 are equal.

and that's where PHP starts

and that's where PHP starts to lose it's mind...

(int) "x"should be cast to NaN, not 0, as it is not a number! http://en.wikipedia.org/wiki/NaN

But then you run into

But then you run into problems. On certain platforms Perl doesn't handle the string "NaN" correctly. Not defending PHP, just saying.

I'm not talking about the

I'm not talking about the string "NaN" i'm talking about the value NaN which PHP does understands.

var_dump(NaN === NaN);

bool(false)

ATOI - it's C's fault not PHPs

php uses atoi, atoi("x") returns 0

Use a sane language like Javascript then!

In Javascript:

  '\t\r\n' == 0 --> true

  "false" == "0" --> false
  "0" == 0 --> true
  0 == false --> true
  false == "false" --> false

  "1" == "01" --> false
  "01" == 1 --> true
  1 == "1" --> true

Why comparing?

And why should I compare with boolean? To get another boolean?

And if you are casting "x" to int, you are probably doing something wrong.

There are ways to test if a string is numeric. For me, test a variable to know if it's numeric before casting is smarter than casting to NaN, and after that, compare value with NaN.

PHP converts values to keep simple comparisions like:
"150" == 150

If you don't know what are you doing, I suggest you study a little bit about the language, or use always ===.

Simple like this.

This is the kind stuff that you can see

in a Zend certification Exam.

Mathematicians have beaten you to it

In algebra, which is a bit older than php, it works this way:

Start with this given:
1) a = b
Multiply by a:
2) a^2 = ab
Subtract b^2
3) a^2 - b^2 = ab - b^2
Factor:
4) (a + b)(a - b) = b(a - b)
Divide by (a - b):
5) a + b = b
Substitute equation 1) (a = b):
6) 2b = b
Divide by b
7) 2 = 1

So, we've known that 2 = 1 for quite awhile.

There are lies. There are damned lies. And then there are statistics. - Mark Twain.

No, that's not math.

"Divide by (a - b):" ...from the first line, you said a = b, so now you're telling us to divide by 0 and expect to be surprised when weird things start to happen? :P

You said "multiply by a", but

You said "multiply by a", but you did this:

a^2 = ab

You probably meant this:

aa = ba

The evaluation of "aa" will be the same as the evaluation of "a^2", but they are completely different operations. You didn't apply them to both sides of the equation correctly.

You're dividing by 0, which

You're dividing by 0, which is undefined in Math. Learn some, it'll help.

TYPES!

If you read the lines for what they actually mean there is no problem.

FALSE == $a means FALSE and $a have the same value when treated as booleans.
$a == $b means $a and $b have the same value when treated as integers.
$b == TRUE means $b and TRUE have the same value when treated as booleans

Sure, you could make it appear more consistent topically but that would make the weak-typing less handy. As usual, everything is a balance.

I am very much pleased with

I am very much pleased with the contents you have mentioned.Airport parking I wanted to thank you for this great article.Tier 4 approvedI enjoyed every little bit part of it and I will be waiting for the new updates.Highly Trusted Sponsor It is very nice article! Just want to say thank you for the information you have shared. Just continue writing this kind of post. Thanks. gatwick meet and greet