5 ms·
Throwing away data without unavoidably good reason is BAD behavior. Period. We've got gigabytes of RAM and terabytes of storage to work with; don't throw away
by ctdonath 15y ago
Throwing away data without unavoidably good reason is BAD behavior. Period.
We've got gigabytes of RAM and terabytes of storage to work with; don't throw away characters in a string just because they don't fit in a compact data type used only because there is a passing resemblance of one to the other.
If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE.
- nbpoole 15y ago> If I'm comparing two 53-digit barcodes, and they differ only by the last digit (checksum), then it's very important that comparing those two STRINGS comes up FALSE. Then use === and do a type-strict comparison. <?php // Prints bool(true) var_dump('9223372036854775807' == '9223372036854775808'); // Prints bool(false) var_dump('9223372036854775807' ==='9223372036854775808');
- ctdonath 15y agoLast week I spent 4 hours trying to find what turned out to be a missing = because C++ will not complain, but will behave very differently, when = is confused with ==. Now you want to add === to the mix? I'll stand by the axiom that throwing away data should NOT occur unless no other sensible option is available. If I'm comparing two literal strings, I shouldn't have to start with the obscure knowledge that a simple comparison will result in an aggressive attempt to perform two consecutive non-obvious type casts high risk of data loss. I'm reminded of the great Belkin router fiasco: wireless routers were shipped with the "hold muh beer" great idea that random web page requests would be redirected to Belkin ad pages. I don't buy Belkin products any more (and that was years ago now) because knowing they would go there broke the trust that they wouldn't. Ditto here: if PHP is going to go to great lengths to try to throw away critical data (hey, I'm storing those numbers as strings BECAUSE I need all the digits), then I can't trust that the language won't do other similarly stupid things. I'm working in an industry where such a cavalier attitude to data can cost MILLIONS of $$$ over one failure, and can't afford to use a language where such failures are systemic. That there exists a workaround is inadequate. </tangent> Fine. I could use ===. The problem remains that a fundamental axiom of the language design is that casting lossless to lossy data types, without direction or warning, is considered acceptable. Ya know, if PHP wants to convert my numeric strings to integers for comparison, fine ... IF it maintains precision and preserves all the data. I shouldn't have to know of and use other operators/functions to explicitly avoid a pathological pursuit of forgetfulness.
- ajross 15y agoNo offense, but it took you four hours to chase down a syntax error? If it survived long enough to see that kind of debugging effort, it was almost certainly dead code; seems like a unit test would have caught it before the first commit. And what compiler are you using? GCC certainly will issue warnings when the result of a = operator is used in a boolean context.
- ctdonath 15y agoUh, the unit test being executed before the first commit was failing. It's a logic error, not a syntax error. And I was using GCC, which is happy to assign values amid a more complex logical evaluation. Try: if ( x = y && p ) return -1;
- ajross 15y ago$ echo 'int foo(int x, int y, int p) { if(x=y&&p) return -1; return 0; }' > test.c $ gcc -Wall -c test.c test.c: In function ‘foo’: test.c:1:1: warning: suggest parentheses around assignment used as truth value [-Wparentheses] This warning has been there since at least gcc 2.x, I believe. I'm not making fun of you, really. But seriously: if you are spending 4 hours chasing bugs that can be trivially found by turning warnings on in your compiler, you have some process issues unrelated to C or PHP syntax.
- ctdonath 15y agoIt likes if ( (x = y) && p ) return -1; (No, I don't have the exact statement in question handy. It was more complicated than this example.)
- jeltz 15y agoYes, and that is because "(x == y) && p" should be written as"x == y && p" according to gcc. If you add the brackets gcc takes that as a sign that you really wanted to do an assignment.
- whateverer 15y agoThat's an opt-in workaround, and proposing it as a solution is like trying to cover the Sun with your thumb. You'll have an infinite number of errors everywhere you can input numbers where the == operator is used, but you can only choose to use === in the finite number of expressions that you, yourself, write. This is insane!
- hluska 15y agoI was trying to figure out a concrete example why this behaviour was dangerous, but couldn't come up with anything. Thanks for your barcode example - it eases my mind (and I'll use it in arguments with my friends!)