> Bad Javascript idiom you won't find in many other languages.
It's not an idiom, and identity tests exist in other languages. You may know them as "==" (Java), "is" (Python), "eq?" (Scheme) or "object.ReferenceEquals" (C#).
Now the syntax is ugly and this does not excuse the fucked up non-overridable equality, but aside from that `===` works pretty well in Javascript.
As opposed to PHP, which famously did manage to even fail implementing identity correctly[0].
It also has nothing to do with the comment you replied to, which uses `== !` (to operators, an equality to a negated operand)
I'm "ok" with that, it's a property of non-overridable equality tests, where arrays are "standard objects" (with natively implemented lots of things, but still objects) rather than built-in magical special cases of the language (although there are still things done by arrays I don't think you can do without recent extensions to the spec, such as
js> var a = []
js> a[42] = 3
3
js> a.length
43
) as opposed to e.g. Go where a few blessed types have access to features Go users do not have any possible access to.
It bothers me significantly more that
[1] == 1
does not return false in JS. Although the rules through which this is reached are clear.
It's not an idiom, and identity tests exist in other languages. You may know them as "==" (Java), "is" (Python), "eq?" (Scheme) or "object.ReferenceEquals" (C#).
Now the syntax is ugly and this does not excuse the fucked up non-overridable equality, but aside from that `===` works pretty well in Javascript.
As opposed to PHP, which famously did manage to even fail implementing identity correctly[0].
It also has nothing to do with the comment you replied to, which uses `== !` (to operators, an equality to a negated operand)
[0] http://developers.slashdot.org/comments.pl?sid=204433&ci...