4 ms·
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 distu
by time_management 18y ago
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.
- wvenable 18y agoThe 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.
- time_management 18y agoWhy 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/().
- wvenable 18y agoOn 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.
- time_management 18y agoThis 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.
- cosmo7 18y agoDon't blame C. This is usually the point that programmers realize why statically typed languages are such a good idea.
- time_management 18y agoWhen 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.
- apexauk 18y agoin 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 18y agoThis 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 18y agoThere 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.
- apexauk 18y agoagree 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.
- gtani 18y agoi 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
- deleted 18y ago[deleted]