On 14/05/2015 23:15, Adam Roach wrote:
On 5/14/15 16:33, Gijs Kruitbosch wrote:
Can you give a concrete example where you had to change a
contributor's patch in frontend gaia code to prefer === to prevent
real bugs?
From what I've seen, it's typically a matter of making the results
unsurprising for subsequent code maintainers, because the rules of
what gets coerced to what are not intuitive.
This isn't what I asked, though. I have seen the argument you're giving
(and Crockford's and similar examples) many times - they're fun party
games - but never cases in the real world where this is an issue.
I'll crib from Crockford's examples (cf. "Appendix B: The Bad Parts"
from "JavaScript: The Good Parts"). How many of these can you
correctly predict the result of?
1. '' == '0'
2. 0 == ''
3. 0 == '0'
4. false == 'false'
5. false == '0'
6. false == undefined
7. false == null
8. null == undefined
9. '\t\r\n' == 0
Our code style means none of 4-7 should actually ever happen - it
explicitly says, do not compare directly to |true| or |false|.
If given the following examples:
foo === undefined
foopy === bar
bar === null
blah === 0
how many can you correctly predict? None, because there is no context
where the variables came from.
Nobody ever compares two literals to each other, and because our
codebase has no type annotations, you never have enough information to
decide what the result of the comparison is without knowing context,
irrespective of which operator you use.
If I have a function signature like this:
function foo(x, y, z)
and these calls:
foo(x);
foo(x, null, z);
foo(x, uriRef, z);
(based on actual examples of some of our URI loading wrappers in browser
frontend code)
inside foo, I really don't want to use strict equality for checking if y
is present or not. Checking against null or undefined would fail in at
least some of the cases.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
