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.
>>> 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.
> You're arguing that === always makes code clearer, and that explicit checks
> are always possible. I disagree with both.
Looks like we're in for some more disagreeing then.
> 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.
> 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.
> 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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
