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.
Then use === and do a type-strict comparison.
<?php
// Prints bool(true)
var_dump('9223372036854775807' == '9223372036854775808');
// Prints bool(false)
var_dump('9223372036854775807' ==='9223372036854775808');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.
And I was using GCC, which is happy to assign values amid a more complex logical evaluation. Try: if ( x = y && p ) return -1;
$ 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]
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.
(No, I don't have the exact statement in question handy. It was more complicated than this example.)
'=' vs '==' is not a syntax error. Consider "x=y=z" vs "x=y==z". And it's in somebody else's code. And they wrote it 2 months ago, but the programmer who's using it has only just started working with it. And they are super busy and don't have time to look at it. And it sort of looks like the problem is in the code you changed last week.
You can easily lose 4 hours over this stuff... have some imagination ;)
I addressed the "someone else wrote it two months ago" point above: If that happened, and this was in the code, it was dead code for two months, because it clearly couldn't have been running correctly. That's a process problem, not a syntax issue, and the appropriate fix is clearly not to modify the syntax of the language.
(Edit for ctdonath: good grief. 1.) the reply was to to3m's post, not yours. 2.) The "two months" thing comes straight out of his example, please read it. 3.) It was a JOKE, based on his chiding me for language. 4.) Why are you still flaming about this?)
I'd written the code the day before, and it was failing a pre-commit unit test. As I posted elsewhere, this kind of "forgot the second =" error can compile without warning, esp. within a complex evaluation. The process was running fine, as it caught the existence of the logic error early. That it took hours to find was a matter of tracing symptoms back to cause in an embedded system not easily debugged when running.
One could make a valid argument that this is a problem of language syntax, as everyone has been bit by the = vs == difference. As such, and in line with this thread OP, you'd think a new popular language would learn from that mistake and would not throw === into the mix as a solution to an even more obscure problem (casting a string to a float? really?).
Uh, all reasonable compilers warn about ambiguous use of = as a truth value.
$ g++ -Wall -c a.cc
a.cc: In function ‘int foo(int, int)’:
a.cc:2:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
$ clang++ -Wall -c a.cc # output is colored
a.cc:2:9: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
if (x = y) return 0;
~~^~~
a.cc:2:9: note: place parentheses around the assignment to silence this warning
if (x = y) return 0;
^
( )
a.cc:2:9: note: use '==' to turn this assignment into an equality comparison
if (x = y) return 0;
^
==
1 warning generated.Every half-decent compiler will spit warnings at you, though.
> Now you want to add === to the mix?
It's been this way forever. PHP does all these conversions intentionally and trusts that you want them done. If you don't, go write C++ with FastCGI yourself. The difference between == and === is something you should pick up within your first few days of using PHP - what kind of industry has an economy measured above the "MILLIONS of $$$", but can't afford a dedicated PHP programmer?
I'm almost glad there isn't an official first-party public bug tracker, mailing list, etc. for Javascript - it would be ten times worse than this.