41–50 of 185 posts
PHP introduced "===" and "!==" a long time ago, and every programmer should know that they have to use that, without any excuses.
Also, don't use "in_array($a, $b)", but use "in_array($a, $b, true)" instead.
Earlier quoted context omitted.
> you should probably use === by default. unfortunately this can also backfire if your class/module is used in a different context where it gets strings instead of integers and you were just using === without really thinking about it: We had a case where the code was something like: function doSomething($value) { if ($value === 0) { //do something } else { //do something else } } This was then used in a slighly diffe…
You're describing the expected behavior of === and a bug. This is not the === operator "backfiring."
As always, you should be thinking when programming.
Earlier quoted context omitted.
PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Is it objectively worse than type coercion in JavaScript?
PHP: var_export(0 == "hello"); // true JavaScript: console.log(0 == "hello"); // false
Earlier quoted context omitted.
PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Is it objectively worse than type coercion in JavaScript?
PHP: var_export(0 == "hello"); // true JavaScript: console.log(0 == "hello"); // false
Or, did you mean that PHP and JavaScript were neck-and-neck all the way up to that one example, and ultimately it's the very one that proves PHP's type coercion is worse?
Earlier quoted context omitted.
I think you meant “=”, not “==” (though the latter would work with bash).
Well, either in the example. Parent was saying "Reminds me on bash" For sh version, I'd go with super-safe: if test "x$1" = "x$2"
Reminds me on bash, where I also have to prefix values to compare with x, to be able to handle empty vars. if [ x$1 == x$2 ]; But automatic string to float conversion is just crazy, esp. in comparison context. Perl, which is equally soft, has at least numerical and string comparison operators. $ perl -e'print "0e462097431906509019562988736854" == "0e830400451993494058024219903391"' 1 $ perl -e'print "0e46209743190650…
Actually, you don't prefix with “x” to handle empty vars, but special characters, as Stephane Chazelas recently reminded: http://www.zsh.org/mla/workers/2015/msg00797.html
All of this I can understand, but why then octal numbers are not compared the same way is beyond me? var_dump(0xA == '0xA'); // bool(true) var_dump(012 == '012'); // bool(false)
I'm not exactly clear on how PHP == works, but you can see the MD5 for yourself: $ echo -n 240610708 | md5sum 0e462097431906509019562988736854 - $ echo -n QNKCDZO | md5sum 0e830400451993494058024219903391 - $ echo -n aabg7XSs | md5sum 0e087386482136013740957780965295 - All of them start with 0e, which makes me think that they're being parsed as floats and getting converted to 0.0. This is why "magic" operators like =…
Same goes for the `0E` prefix with an uppercase E The likelihood of generating a hash value with that kind of prefix is 2 in 65536. Finding a collision `hash(a) == hash(b)` with this "weak" equality comparison is approximately 1 in 256 if I'm not mistaken.
The prefix is not sufficient though, the suffix must be entirely decimal otherwise it's not a valid number in scientific notation.