> 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.
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.
The fact is, if you look at it in this abstract way then your feelings are valid. But during concrete web development, the functionality of PHP's comparison operators make a lot of sense and make the code simpler and easier to understand.
Why is this? I'm not sure I understand where the gain is.
I guess that, for me, the cost of a few keystrokes involved in writing "if x == 0 then ..." vs. "if x then ..." never seemed to be worth the hassle of remembering false values. I've always found it preferable to make the comparison being made explicit.
I also generally dislike the practice of using reserved values to signify empty data, e.g. 0 for missing numerical data. I prefer to use ML-style option types, e.g. None vs. Some 0, and in a dynamically typed language, I'd just use the nil/().
On the web, all the data comes in as strings including numbers. So the comparisons work well the numbers in strings. The rest of the weirdness comes from PHP copying C and Perl semantics.
When I moved from Java to Python, I was sure that dynamic typing was the way to go, because the type system in the C/Java family is such a hindrance, while lacking the power of a mature type system as seen in ML or Haskell. When I moved from Python to ML, I was equally adamant about static typing being the way to go, because the ML type system is pretty awesome in terms of compile-time error-checking and documentation. Now that I'm learning Lisp, I'm open to the benefits of dynamic typing, or at least want to keep an open mind about the matter.
This makes sense. I guess a programmer who does a string => bool type conversion desires different behavior than one who does string => int => bool, so the fact that they produce different results ("foo" => true vs. "foo" => 0 => false) is part of the design.
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.
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?
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.
agree about failing loudly when bad stuff happens - but exceptions are best reserved for truly exceptional circumstances. in webdev everything arrives from the browser as a string so implicit casting is more of the norm. if your user enters something dumb into the quantity field of your shopping cart it doesn't really warrant abandoning the rest of their input and leaping back up the call stack to a "misson failed"-level error handler.
functions like is_numeric('string') exist for the rarer situations where things like this actually matter, but php's default way is simply reflective of it's nature as a loosely-typed language.
i believe these casts, or whatever the implicit coercions are called, follow the perl rules, and along with rules for truth and falsehood, behave predictably. The chart is kind of overkill
Blogspam is the bane of the internet...