PHP's == has a lot of oddball effects. They were put in so that things would behave the way a novice expects them to (3 == '3') but would confuse more experienced programmers, or those coming from other languages.
Unless you're deliberately taking advantage of automatic type conversion and whatnot, you should probably use === by default.
> They were put in so that things would behave the way a novice expects them to (3 == '3')
It's a very wrong approach. It may look like newbie-friendly, but in fact it makes it much harder to learn and use. Any novice will be constantly attempting to form a mental model of what's going on and how the language interprets concepts. Refusing to do things like 3 == '3' is simple and makes sense. Assuming a programmer is an idiot and trying to outguess his mistakes makes the language so complicated, that the novice will not be able to form a coherent model and will most likely assume that "this thing is magic".
It's hard for newbies who want to master the language. It's not hard for people who have no interest in learning a programming language and just wan't to make the thingy in their HTML do some stuff.
Register globals,
<?php
if ($category == 2) {
echo 'Foo';
}
?>
and be done.
We have to remember the PHP origins and audience from way back to understand why this was considered easy to use.
That's actually interesting. It's not obvious to me that "2" should be parsed as an int and not a string. Perhaps we should either be explicit about what we want "2" to be parsed as (int, long, float, double, bigint, bigfloat, string...) or let the parsing of a number be determined in a more dynamic way. If you're comparing a string with an integer literal, then you probably want the string interpretation of the literal, right?
We are pretty sure what the literals mean. On the other hand we have many string channels: get/post/cookie/persistent storage¹/… Given that environment its probably natural that you try to convert a string into its "intended" type.
¹no DB, but the "just write your visitor counter into a plain text file" back then
News to me. You have to enter a really high-precision number as a string in Java so it won't be rounded off to fit within a double. This is an unsolved problem.
shhhhh, people don't realize PHP started out as just a tool for Rasmus and ended up evolving. No, to them, PHP was DESIGNED this way on purpose from the ground up.
Of course not, but everyone keeps comparing PHP to languages that were designed and developed to be languages, not a toolset that some crappy developer (his own words) created for his personal site that ended up evolving and becoming a real language.
It's got quirks, we get it. Let's keep improving the language as we go instead of constantly bashing it. I mean PHP is one of the most widely used languages on the web today.. Clearly it's doing something right.
Designers of future languages, please take this example as a proof of the rule: don't design anything for newbies. They will find a way to make an error anyway, but dumbs-based design will be the problem for everyone else.
That - and the error is going to be a lot more subtle and harder to find.
In all fairness though, it's a balancing act - There are benefits to dynamic typing, but PHP clearly overdid it. (See also the disaster that was/is magic quotes)
Incorrect. However, (0x33 == '3') will return true, as will (51 == '3'). Your point is valid, even if your code is wrong. Automatic type coercion can produce unexpected results in any language.
PHP's automatic type coercion rules are designed to help newbies at the expense of experienced developers. C's automatic type coercion rules are, largely, designed to expose the underlying memory layout to developers who know what they're doing, at the expense of inexperienced developers. Both can easily contain dangerous pitfalls, but I prefer the latter philosophy over the former.
(Disclaimer: I have built a career as a C programmer and frequently use its lower-level features to great advantage. I am biased.)
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 different context where $value was a string '0', it then ended up incorrectly in the //do something else block, doing the completely wrong thing. In this case the type co-erced == would have been better, and I think what the developer was expecting would be a type error due to the === but it's not a type error, it'll just fall into the else block.
Absolutely, I was just suggesting that "you should always use the === operator" advice which I see a lot of people say(examples multiple times in this thread), does not guarantee you won't run into problems with incorrect types, and giving an explanation.
As always, you should be thinking when programming.
Unless you're deliberately taking advantage of automatic type conversion and whatnot, you should probably use === by default.