4 ms·

PHP cheat: ==, ===, empty(),is_null(),isSet()

• tptacek 18y ago
  This is PHP? Sold!
• nuclear_eclipse 18y ago
  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 http://www.php.net/manual/en/types.comparisons.php Blogspam is the bane of the internet...
  • Harkins 18y ago
    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 18y ago
      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 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 ago
    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.
    • time_management 18y ago
      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/().
      • wvenable 18y ago
        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.
        • time_management 18y ago
          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.
        • cosmo7 18y ago
          Don't blame C. This is usually the point that programmers realize why statically typed languages are such a good idea.
          • 18y ago