On 14/05/2015 19:08, Martin Thomson wrote:
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
<gijskruitbo...@gmail.com> wrote:
I mean, obviously the example is simplified. You seem to think that "==="
means "I'm sure this will be the right type". In the same way you imply that
== indicates uncertainty about type (or acceptance of multiple types), I
would argue that when I see === I get suspicious about whether the code
could be failing because it gets passed a similar-but-different-type value
(false vs. null vs. undefined vs. NaN especially).
If you intend to support false and null and undefined and NaN and
attribute the same semantics, _say so_. Make it explicit. Don't make
me (the person reading your code years later) that this is your
intent.
Then why is if (!foo) OK and do you not prefer:
if (foo === false || foo === undefined || foo === "" || ...)
? Why do I not have to make it "explicit" (which is a word I think
doesn't make sense here, see below) in that case?
if (arg) {
dosomethingwitharg(arg);
}
I'm actually perfectly fine with this form. Including something in a
conditional statement is pretty damned explicit as far as I'm
concerned. It's at least as clear as if (!!arg) and easier to read.
(I have a personal bugbear against the falsy-ness of the empty string,
but I can concede that point.)
I don't understand the distinction you're making, then; why is the type
coercion OK here but not for == ? Surely this is being just as "lazy" as the
other case?
Because it's explicit. if () takes a boolean.
See above.
As noted above, === creates just as many uncertainties as == for the reader.
The solution is testing (and in some cases comments), whichever operator we
pick.
No, you are suggesting that === cuts out some code paths or options
that might be wanted. But it doesn't, it only forces you to be
explicit about your intent in including those options.
"==" is not any less explicit than "===". Both versions have an exact,
specified meaning. Representing the meaning of "==" as a con/disjunction
of "===" statements will of necessity be more verbose.
Alternatively, if you only need a subset of the "==" meaning, you will
restrict the conditions under which the expression returns true, but it
is not "being more explicit".
It is saying something different, much like "foo > bar" is not the same
as "foo >= bar" - given the same foo, the first expression will just be
true in a subset of the cases where the second expression is true.
in bar.html, checking the type of foo using instanceof with Array fails. For
builtin Arrays we now have isArray, but this does not work for custom JS
classes or DOM elements.
That's a legacy failure, but not one to solve with further obfuscation.
I will again say that "obfuscation" and "explicit" is not what is at
issue here, IMO. The meaning of "==" is perfectly clear and specified,
just like "===". The cases where the result is "unexpected" is where
people have not thought through the values on which the operator, err,
operates. Such cases exist for both operators. There might seem to be
more for "==" if and only if you show people literals, like "wtfjs" and
friends. My point is there will be just as many "unexpected" issues when
you use "===" on opaque variables, because you didn't expect that that
code in that other file set this thing to null instead of deleting the
property (causing it to not be === undefined in your comparison) -- for
example.
Maybe there is a difference with firefox browser JS and platform JS here
(on which you seem to be working), in terms of which kinds of type
confusion are likely and that need thinking about, but IMO that just
strengthens Mike's case that we should let people write whatever they're
comfortable with.
Also, if you're very serious about wanting to effect this change, you should
probably take this to fx-dev, as the style guide is specifically about
chrome/firefox JS.
I'm serious.
I originally posted to fx-dev. You appear to have removed it from CC.
Oh shoot. Sorry. Re-added; I read this list over news:, and somehow the
mailing list responses include both the ng and the identical ml, and I
must have gotten confused and removed both fx-dev and the dev-platform
list (I do need to remove the identical ml, otherwise my replies show up
twice). Apologies.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
