5 ms·
What the parent was saying regarding the == vs === is that unlike other languages it's very easy to get burned if you don't know the difference and when to prop
by artmageddon 14y ago
What the parent was saying regarding the == vs === is that unlike other languages it's very easy to get burned if you don't know the difference and when to properly use it. I'm hardly proficient at JS and not knowing that would've screwed me over.
- chris_wot 14y agoCan you give me a concrete example?
- mnarayan01 14y ago0 == false or even better "0" == false edit: I should note that I don't think JS is a horrible language or anything, but it does have more than its share of oddities.
- chris_wot 14y agoI guess I'm still confused... Where abouts in your code will you be comparing a string or integer to a Boolean? Incidentally, there are quirks - the worst is with having to define a "that" variable, I guess I just don't see these JavaScript issues as all that terrible. Unlike PHP's type coersion system, Javascript's is quite sensible.
- lucian1900 14y agoThe point is that comparisons between things of different types should be errors. Implicit coercion is never sensible.
- Turing_Machine 14y ago4 / 2.5 should be an error? Okay, then. Never mind that essentially no language in widespread use enforces that.
- lucian1900 14y agoThat case is also potentially problematic, but perhaps better solved by having float division / and integer division // as separate operators. Perhaps my "never" was too strong.
- mnarayan01 14y agoIf you have a function which returns an integer or false.
- chris_wot 14y agoThat, I would hazard to advance, is a very poorly written function.
- ufo 14y agoThe most common `==` problem is `0 == ""`, IMO
- tobyjsullivan 14y agoAs if that wasn't bad enough on it's own. "0" == false and "" == false but "0" != "" Edit: Or maybe a less defendable example of my point: "0" == 0 and "" == 0 but "0" != ""