I wrote it like that in some code I posted here one time, not
realizing it was a big deal. The reason I wrote it that way was
because I know typeof returns a string primitive, so I felt the code
was better (self-)documented by writing ===, because it's like saying
"that expression on the left should always give a string primitive" in
case the reader 'forgot' or whatever. I guess the fact that you're
comparing it to a string on the right is probably enough, I just felt
(at the time) like === made the whole statement more explicit.
This is an interesting reason, I should admit. Sort of, vice-versa --
you /know/ how standard operators or function work (values of which
types they return), but use === anyway just to make it more explicit
(possibly, by the ideology -- "explicit is better than implicit").
The
whole thing sounds like a stylistic issue to me;
Possibly. And maybe even yes. What I thought. The note as its now --
really looks like a bit emotional but not analytic write-up. I don't
like this stylistics, it isn't mine (if to consider all other chapters),
it's not my reputation.
Although, I wanted to show that == and === are completely equivalent and
there is no any magic in ===, I should admit that the current style
sounds like I'm forcing my readers to use == when it can be used. Even
the notes I've made (that is not so, and the note is just to show
specific safe-cases) are not enough.
Still it can sound like Jorge has heard it -- like a nit-picking to
non-essential thing. And that is worse, just like I'm calling as
"idiots" those who use === with `typeof`. I want to assure that /it's
absolutely not so/, the thing was to point the technical detail, that
they are equal and there are safe cases.
But I've made one mistake -- the note is small if to compare with other
my articles. But at the same time, the note is big for the reason I
wanted to write it -- I should did it in two sentences, but then the
article would have no sense. Objectively, it may have no sense even now.
But I hope, who have understood it correctly, the sense is. Anyway, it
wasn't vain that I mentioned it -- because some programmers change their
mind in this question.
But if the answer for the question is:
"I don't even think and don't care about whether these algorithms are
equal or not, I just _use_ === as it would be the only one equality
operator in the language. Yes, I like to write all that explicitly,
because it helps me not to confuse in the code. Like in Python. You said
yourself that all languages should be so -- not to confuse a programmer
with thinking on some irrelevant with the major task thing -- a ==
operator. I just avoid such situations."
And this is correct. But I mentioned the same.
So, what have I decided? I'll a bit rewrite this article, removing all
the emotional stuff such as ("If the cost is the same, for what to buy
this `stuff`?"). But, of course I won't refuse from the article, still
the technical part that there are cases as `typeof` and that algorithms
are equal is at least -- "a good to know".
Once again, it's _not_ a nit-picking (and this thing I didn't want the
most), but unfortunately it can sound like it (and Jorge is right from
this position). Because, if so, there can be case when someone will
catch me on using `[1, 2, 3].indeOf(1) === 0` and I should explain, why
did I use it after such article. And even if I said about my rules --
that I can use both == and === whenever I want, it will sound odd.
I describe some pit-fall cases (including "falsy" values and boolean
cases), but still mention that == is the same as === in some safe-cases.
At the same time I won't recommend to avoid something (as Crockford
did). Sort of as VK suggested.
the functionality of
the two operators in the case of typeof is basically identical as
discussed here ad nauseum.
Yes, and this is what I wanted to say, identically of the == and === in
such case.
Dmitry.
