

PHP cheat: ==, ===, empty(),is_null(),isSet() - gtani
http://www.blueshoes.org/en/developer/php_cheat_sheet/

======
nuclear_eclipse
So, it's just a colorized, otherwise identical rip off of what PHP already
gives you as part of their official documentation?
<http://www.php.net/manual/en/types.comparisons.php>

Blogspam is the bane of the internet...

~~~
Harkins
It also lacks the bolding and heavy cell borders and gutters that turn the PHP
manual's table into a wall of gray noise. It's a solid improvement.

~~~
tesseract
This wording...

> The PHP Documentation Group has now added the Appendix K. PHP type
> comparison tables to the official PHP manual.

...seems to make the claim that the linked article came before the PHP
manual's version. I'm too lazy to verify (e.g. by checking archive.org or
something) though.

------
time_management
I'll admit that I know nothing about PHP, but please tell me it is a mistake
in the design table that they have "foo" == 0. Otherwise, we have this rather
disturbing* non-transitivity of (==):

true == "foo" == 0 == false

I also generally dislike the idea of having certain values being treated as
"false", e.g. 0 is false but 2.2e-16 is true... or "a" and "1" are true but
"0" is false. It just seems to be clumsy, and not very robust. It reminds me
of the "and-or trick" in Python, which busts if you aren't familiar with the
fact that values such as 0/0.0 are false.

* Actually, on review, it's obvious that some non-transitivity is desirable by design, in the sense that 1 and 2 are both "true" but we don't want 1 == 2, even though 1 == true and 2== true. However, I still maintain that the chain I have above represents bad design.

~~~
apexauk
in PHP "foo" == 0 due to how php handles type juggling - the string is
converted to an integer before the comparison, with strings that don't contain
numbers converted to 0. so "foo" == 0 and "0" == 0 but "1" != 0.

~~~
time_management
This makes more sense, but I still find it odd and disagreeable. I tend to
prefer that my programs fail loudly, so I'd write string -> int conversion to
raise an exception on seemingly non-numerical input like "foo", "ba6r.5",
"pwn3d", etc. Then again, admittedly I know very little about web development.
Is it not practical to do this?

~~~
Zak
There is nothing special about web development that makes implicit typecasting
or returning an arbitrary value when a cast fails instead of raising an
exception a good idea. Another reasonable option is to return NaN (Javascript
does this) or null.

------
tptacek
This is PHP? Sold!

