Note 2. ECMAScript. Equality operators.

[Dmitry A. Soshnikov]

Hello,

Here is the small note related to the topic which I've mentioned before
several times on forums and news groups -- about equality operators and
cases of their usage. This note is the summary of that thoughts.

"Note 2. ECMAScript. Equality operators."

<http://dmitrysoshnikov.com/ecmascript/note-2-ecmascript-equality-operators/>

Additions and corrections are welcome.

Dmitry.

 

[VK]

Hello,

Here is the small note related to the topic which I've mentioned before
several times on forums and news groups -- about equality operators and
cases of their usage. This note is the summary of that thoughts.

"Note 2. ECMAScript. Equality operators."

<http://dmitrysoshnikov.com/ecmascript/note-2-ecmascript-equality-oper...>

Additions and corrections are welcome.

1. Your == vs. === analysis sounds rather eclectic:
....
"I’d like to point out that there are cases when strict equal === is
absolutely useless and its usage in some places can be treated as
ignorance and misunderstanding of the ECMAScript."
....
"Therefore, repeat, if you feel that you forgot what some operator or
function returns and need to consider the type, use the === operator."
....

A programmer might just have chosen === as an only operand exactly to
not be bothered with == subtle issues and to concentrate on other more
important things. It is not a reason to judge on his ignorance and/or
misunderstanding of JavaScript, as you properly conclude at the end of
the article as opposed to its beginning. So I would change that
starting "clj cabal pleaser" to a lesser aggressive and logical
version:
"I'd like to point out that there are many cases when strict equal ===
is non-necessary and when it doesn't bring any additional robustness
to the code".

2. To make your equality summary more full, I would:
a) provide a link to the type conversion rules for comparison
operators in JavaScript
b) add the subtle yet existing case of Boolean object with false
value and how to get the false result from such comparison.

 

[Dmitry A. Soshnikov]

1. Your == vs. === analysis sounds rather eclectic:
...
"I’d like to point out that there are cases when strict equal === is
absolutely useless and its usage in some places can be treated as
ignorance and misunderstanding of the ECMAScript."
...
"Therefore, repeat, if you feel that you forgot what some operator or
function returns and need to consider the type, use the === operator."
...

A programmer might just have chosen === as an only operand exactly to
not be bothered with == subtle issues and to concentrate on other more
important things. It is not a reason to judge on his ignorance and/or
misunderstanding of JavaScript, as you properly conclude at the end of
the article as opposed to its beginning. So I would change that
starting "clj cabal pleaser" to a lesser aggressive and logical
version:
"I'd like to point out that there are many cases when strict equal ===
is non-necessary and when it doesn't bring any additional robustness
to the code".

You know, I thought the same. Yes, such conclusion sounds more analytic,
but not emotional. I like it, thanks; updated to your proposal.

2. To make your equality summary more full, I would:
a) provide a link to the type conversion rules for comparison
operators in JavaScript

OK, added links to additional literature.

b) add the subtle yet existing case of Boolean object with false
value and how to get the false result from such comparison.

Yeah, good example when == can take its place. Added.

Dmitry.

 

[Dmitry A. Soshnikov]

On 26.06.2010 15:07, VK wrote:

A programmer might just have chosen === as an only operand exactly to
not be bothered with == subtle issues and to concentrate on other more
important things.

I added this sentence too to be fair.

Dmitry.

 

[VK]

I added this sentence too to be fair.

Another issue can be found in the discussion "The strange story of !
and ==(=)false" and it's in reference with your comment:
http://dmitrysoshnikov.com/ecmascript/note-2-ecmascript-equality-operators/#comment-889

Basically there is not The Right comparison as opposed to all other
more-or-less wrong ones. It all depends on what that particular
programmer decided to treat as true or false in that particular
program.

a) any explicit false, explicit 0, null, NaN, or an empty string is
false - anything else is true (that includes "0" string as well).

b) any explicit false, explicit 0, null, NaN, an empty string, or a
string that can be treated as 0 numeric literal value is false (that
includes "0", "00, "0x0" etc. strings) - anything else is true.

b) any explicit false, explicit 0, null, NaN, an empty string, a
string that can be treated as 0 numeric literal value is false (that
includes "0", "00, "0x0" etc. strings), or Boolean with false value is
false - anything else is true.

There can be different combinations between a), b) and c). There are
no rules when and what to treat as true/false for a particular case.
In one project one can care only if a string is empty or not, in other
case it is crucial to sort out all zeros. Respectively there cannot be
any critics on choosing one against other, only detailed explanation
of true/false sets for either case.

 

[Dmitry A. Soshnikov]

Another issue can be found in the discussion "The strange story of !
and ==(=)false" and it's in reference with your comment:
http://dmitrysoshnikov.com/ecmascript/note-2-ecmascript-equality-operators/#comment-889

Basically there is not The Right comparison as opposed to all other
more-or-less wrong ones. It all depends on what that particular
programmer decided to treat as true or false in that particular
program.

a) any explicit false, explicit 0, null, NaN, or an empty string is
false - anything else is true (that includes "0" string as well).

b) any explicit false, explicit 0, null, NaN, an empty string, or a
string that can be treated as 0 numeric literal value is false (that
includes "0", "00, "0x0" etc. strings) - anything else is true.

b) any explicit false, explicit 0, null, NaN, an empty string, a
string that can be treated as 0 numeric literal value is false (that
includes "0", "00, "0x0" etc. strings), or Boolean with false value is
false - anything else is true.

There can be different combinations between a), b) and c). There are
no rules when and what to treat as true/false for a particular case.
In one project one can care only if a string is empty or not, in other
case it is crucial to sort out all zeros. Respectively there cannot be
any critics on choosing one against other, only detailed explanation
of true/false sets for either case.

Yes, that's true, it depends on needs. However, in the comment I didn't
mean some complex combination of particular cases, but just an abstract
example. In general, comment is a reply with showing some other safe-cases.

Dmitry.

 

[Dmitry A. Soshnikov]

On 26.06.2010 20:38, VK wrote:

"0", "00, "0x0" etc. strings

I've added this as an example and recommendation to use (in general,
regardless specific cases) === always if one needs exactly boolean
comparison.

Dmitry.

 

[VK]

On 26.06.2010 20:38, VK wrote:



I've added this as an example and recommendation to use (in general,
regardless specific cases) === always if one needs exactly boolean
comparison.

Probably bringing too much of the human moral and aesthetics (right-
wrong, good-bad) into the programming Boolean logic (true-false) where
the latter is completely indifferent to the first one and vice versa -
probably doing that: I would still say that an average person with
some basic programming experience of *any* programming language has
the "natural" idea of what is true and what is false. These are: any
explicit false, explicit 0, null, empty (where presented), undefined,
NaN, or an empty string are false. I do not recall a single case since
1996 when anyone would be surprised by if(anything from above)
returning false, even if it would be <del>her</del> <ins>his</ins>
first script ever. Somehow it does correlate with the human idea that
the emptiness of any kind cannot be good == true. So maybe the best
structure for an article of the kind (for any language including
JavaScript) would be:
a) to outpronounce this "natural" true-false idea because just like
not every moral bearer can spell the moral rules - in the same way not
every programmer can spell the situations where the false is expected
no matter what.
b) to explain how to get it in that given language
c) to explain what else can be true in the given language. It doesn't
matter how "natural" it can be for the language: if it doesn't
appertain to the "natural" language-independent true-false then it is
contra-intuitive for the majority of readers.
d) to explain the cases that are so specific that may be contra-
intuitive to anyone.

It is not a critics really, just my thoughts I have a chance to share
with not a programmer only but with a writer targeting to normal human
beings

P.S. For the section d) from above my another little gift
JavaScript string comparison goes by the rules of normalized Unicode
strings. Besides other things it means that string literals will be
equal irrespectively to the representation of complex signs: as a
single Unicode char or a combined Unicode char. That means for
instance that a-umlaut can be coded as a single char "ä" or as a +
u0308 (combining daeresis) and both strings will be equal.

 

[Dmitry A. Soshnikov]

On 27.06.2010 23:37, VK wrote:

So maybe the best
structure for an article of the kind (for any language including
JavaScript) would be:
a) to outpronounce this "natural" true-false idea because just like
not every moral bearer can spell the moral rules - in the same way not
every programmer can spell the situations where the false is expected
no matter what.
b) to explain how to get it in that given language
c) to explain what else can be true in the given language. It doesn't
matter how "natural" it can be for the language: if it doesn't
appertain to the "natural" language-independent true-false then it is
contra-intuitive for the majority of readers.
d) to explain the cases that are so specific that may be contra-
intuitive to anyone.

It is not a critics really, just my thoughts I have a chance to share
with not a programmer only but with a writer targeting to normal human
beings

Yeah, I see. It seems that the title of the note is a bit ambiguous. It
isn't a deep analysis of the equality operators in ES (regardless that
the note is named similar). It's just kind of the "eyes opener" that
there are cases when === is not necessary, and if a user find out that
there are some cases, checks such as `typeof foo === "undefined"` will
seem to him just useless.

In contrast, I still think that it's needed to worry a user about subtle
cases (as with `new Boolean(false)`) and to recommend something
practical (e.g. always use === for _boolean_ type checks, excluding even
`new Boolean(false)` object).

If it would be a deep analysis, with describing all cases, including all
subtle cases (which actually I do in chapters, but not in notes) then
yeah -- I think I'd maybe described it somehow in different form. But
this note is just to say, that there are safe-cases, when == isn't not
"bad" and "evil" part of the ES.

Dmitry.

 

[Ry Nohryb]

(...)
If it would be a deep analysis, with describing all cases, including all
subtle cases (which actually I do in chapters, but not in notes) then
yeah -- I think I'd maybe described it somehow in different form. But
this note is just to say, that there are safe-cases, when == isn't not
"bad" and "evil" part of the ES. (...)

In this matter again I agree 100% with Crockford: it's the ==
automatic type casting/coercing what's most of the times a useless
risk. You loose nothing by typing typeof x === "sometype" (it's not
even true as you say that it counts as one more char, not when
gzipped) but you have wasted your time in writing a long-winded page
to defend an hypothetical, dubious advantage in avoiding a strict
comparison where a non strict one would do. I wonder why so many
people keep wasting so much time and effort with the sole purpose of
pretending to be more clever than Crockford. He is him, you just be
yourself.

 

[Dmitry A. Soshnikov]

In this matter again I agree 100% with Crockford: it's the ==
automatic type casting/coercing what's most of the times a useless
risk.

You have your viewpoint (I think/hope it's really but not just forced by
authority), nobody can prevent you of using typeof foo === "string".

But what's the most funny, once people have knew that there is no
difference, after that their hands won't up to write === in such case as
with `typeof` and they write ==. Why? I think, just a human logic --
they see a big contradiction: on one hand -- "authority said" and showed
me some scary synthetic primitive examples with losing transitivity and
some very scary examples with falsy values (which are all == to `false`
-- yeah, in dynamic language). On the other hand they really can't
understand for what any reason they should continue to write === with
`typeof` comparing its result with another string.

You loose nothing by typing typeof x === "sometype" (it's not
even true as you say that it counts as one more char, not when
gzipped)

Yes, the example with losing one "byte" is also very synthetic and
showed just for "fun" (?). On practice of course nobody will think about
"few bytes". As I mentioned myself -- a normal functioning of the system
is much essential than that.

but you have wasted your time in writing a long-winded page
to defend an hypothetical, dubious advantage in avoiding a strict
comparison where a non strict one would do.

No, no way -- that wasn't the goal of that note. The goal was/is to show
that there are /completely/ safe-cases which are /specified/ by the
standard, and which means that /nothing/ can go wrong. And also the goal
to show algorithms of == and ===, and to show they are equal in such
cases. And I'm telling you, after people find out it, they first have
some "systemic contradiction" (for a while) and after that start to
write == with `typeof`. Because when they write a code and reach the
line with `typeof` they /can't/ anymore write === because /understand/
and /know/ that they are safe in this case.

I do not force anyone to write so. Moreover as I said, I think that a
programmer need not remember much about some == to avoid ambiguities.
That all languages should go that way -- increasing of an abstraction to
be able easy understand and remember the language's constructions.
Additionally, I also recommend using === in many cases (including cases
with booleans) and I assume that a programmer can even forgot what
results `typeof` (yeah, really, maybe it results a number? or an object?
and I need a string on the right hand side -- so I use ===), and I
conclude that it isn't a crime to use === everywhere.

I just show the /completely/ safe-cases and that algorithms are equal in
some cases. That's it. No more, no less.

Personally, I use === when is needed, and == in all other cases.
Additionally, if I forgot some case, I use always ===. That's my rules.
And it's convenient for me. You have other rules, which more convenient
for you.

I wonder why so many
people keep wasting so much time and effort with the sole purpose of
pretending to be more clever than Crockford.

Yeah, funny demagogy Don't worry, I have immunity for it.

He is him, you just be
yourself.

Yes, who said different? I am me. I have a name and my thoughts. You
(and any authority you believe) have yours. We can exchange our meanings.

Dmitry.

 

[Evertjan.]

Ry Nohryb wrote on 28 jun 2010 in comp.lang.javascript:

I wonder why so many
people keep wasting so much time and effort with the sole purpose of
pretending to be more clever than Crockford. He is him, you just be
yourself.

What a nonsense, as if programming is about ignoring some figure that is
your personal hero.

Sound argumentation can never be based on adoration of a person,
but only about arguments.

If this Crockford figure has a good argument, be welcome to defend his
meaning, accompanied by his arguments, but adoration won't get you far in a
discussion.

======================

Methinks automatic type conversion is one of the key benefits of a loose
typed scripting languages.

So why not using it if you are profiient enough for your liking?

Programming primarily should be about the joy of programming,
and the time spent on correcting a bug is well spent as it increases your
personal knowledge of such language.

Do you think that this hero of yours got his possibly intimate knowledge
about Javascript from perusing the [missing!] specs, or from personal
frustrating debugging experiences?

Personal frustration should lead to more dexterity, knowledge and
frustration tolerance, but there is the other way of believing in saints
and heros to stem those frustrations. The latter way should be discouraged.

 

[Ry Nohryb]

Ry Nohryb wrote on 28 jun 2010 in comp.lang.javascript:

I wonder why so many
people keep wasting so much time and effort with the sole purpose of
pretending to be more clever than Crockford. He is him, you just be
yourself.

What a nonsense, as if programming is about ignoring some figure that is
your personal hero.

Sound argumentation can never be based on adoration of a person,
but only about arguments.

If this Crockford figure has a good argument, be welcome to defend his
meaning, accompanied by his arguments, but adoration won't get you far ina
discussion.

======================

Methinks automatic type conversion is one of the key benefits of a loose
typed scripting languages.

So why not using it if you are profiient enough for your liking?

Programming primarily should be about the joy of programming,
and the time spent on correcting a bug is well spent as it increases your
personal knowledge of such language.

Do you think that this hero of yours got his possibly intimate knowledge  
about Javascript from perusing the [missing!] specs, or from personal
frustrating debugging experiences?

Personal frustration should lead to more dexterity, knowledge and
frustration tolerance, but there is the other way of believing in saints
and heros to stem those frustrations. The latter way should be discouraged.

Hi Evertjan. There's no adoration over here, nor any heros.

But it happens that most of the times there's a good reason to laugh
at the people that love to nitpìck in Crockford's words in an attempt
to look clever, as in writing a long-winded page just to say that
"there are safe-cases, when == isn't (a) "bad" and "evil" part of the
ES", IOW, just to say that a typeof x == "" is functionally identical
to a typeof x === "". Yeah, right, what's the point in that if not to
nitpick his words ?

His advice is simple and flawless: use of (strict comparison
operators) ===/!== is always preferred because ==/!= do type coercion
and this can mask type errors. Errors that are likely in a language
whose vars can hold any type. And face it: you've got to be very lucky
for the mechanisms of type coercion of the ==/!= operators to suit
your particular needs, in any case. So... you're better off typing
explicitly and unequivocally what you want to check for, using the
===/!== operators instead.

 

[Ry Nohryb]

(...)
Yeah, funny demagogy Don't worry, I have immunity for it.
(...)

Sorry, Dmitry, but face it: he's is right in this one (too).
However you're free to continue with the new sport: nitpicking him

 

[Dmitry A. Soshnikov]

Ry Nohryb wrote on 28 jun 2010 in comp.lang.javascript:

I wonder why so many
people keep wasting so much time and effort with the sole purpose of
pretending to be more clever than Crockford. He is him, you just be
yourself.

What a nonsense, as if programming is about ignoring some figure that is
your personal hero.

Sound argumentation can never be based on adoration of a person,
but only about arguments.

If this Crockford figure has a good argument, be welcome to defend his
meaning, accompanied by his arguments, but adoration won't get you far in a
discussion.

======================

Methinks automatic type conversion is one of the key benefits of a loose
typed scripting languages.

So why not using it if you are profiient enough for your liking?

Programming primarily should be about the joy of programming,
and the time spent on correcting a bug is well spent as it increases your
personal knowledge of such language.

Do you think that this hero of yours got his possibly intimate knowledge
about Javascript from perusing the [missing!] specs, or from personal
frustrating debugging experiences?

Personal frustration should lead to more dexterity, knowledge and
frustration tolerance, but there is the other way of believing in saints
and heros to stem those frustrations. The latter way should be discouraged.

Hi Evertjan. There's no adoration over here, nor any heros.

But it happens that most of the times there's a good reason to laugh
at the people that love to nitpìck in Crockford's words in an attempt
to look clever, as in writing a long-winded page just to say that
"there are safe-cases, when == isn't (a) "bad" and "evil" part of the
ES", IOW, just to say that a typeof x == "" is functionally identical
to a typeof x === "". Yeah, right, what's the point in that if not to
nitpick his words ?

Nice try again But I'm telling you, your attempts are vain. OK, I've
appreciated it, you may stop doing it

Seriously, nobody nit-picking Crockford, he has his meaning on this
question, I have mine. Moreover, I do not contradict his meaning, but
clarify the cases.

His advice is simple and flawless: use of (strict comparison
operators) ===/!== is always preferred because ==/!= do type coercion
and this can mask type errors. Errors that are likely in a language
whose vars can hold any type. And face it: you've got to be very lucky
for the mechanisms of type coercion of the ==/!= operators to suit
your particular needs, in any case. So... you're better off typing
explicitly and unequivocally what you want to check for, using the
===/!== operators instead.
--

I recommend the same. And additionally notice that (a) there are cases
when === just useless (and if you don't know what results `typeof` --
that's just your problem) and (b) in language with dynamic type
conversion, == is an additional syntactic sugar for convenience.

If you need to consider some cases "1" and 1, you need to define it
explicitly with conversion:

if (a === 1 || a.toString() === "1")

and I can even consider that such explicit manual writing can be useful
in some cases. Or just use:

if (a == 1)

this is dynamic language with dynamic and "duck" typing. So, some useful
sugar is provided.

You may write on static language. Because I soon (some paranoiacs) will
first freeze their objects (and I know that in committee there are many
people who want to freeze by default all built-in prototypes and
constructors; and the next stage maybe -- static typing and excluding
first-class objects -- yeah, let's make another Java with that long
names and manual everything).

So, don't understand incorrectly.

Dmitry.

 

[Dmitry A. Soshnikov]

Sorry, Dmitry, but face it: he's is right in this one (too).

That's OK, Jorge, don't worry as I said. I have similar recommendations
and additionally show that everything depends on situation.

As I said, in addition, in scripting language with dynamic type
conversion, == can be just a sugar for someone.

In general, I recommend the same and describe it. But if a person in
learning JavaScript has learned how `typeof` works, writing === with it
will seem to him something strange.

However you're free to continue with the new sport: nitpicking him

You're confusing me with someone else

Dmitry.

 

[Ry Nohryb]

Nice try again But I'm telling you, your attempts are vain. OK, I've
appreciated it, you may stop doing it

I'm not "attempting" anything, seriously: no offense meant.

(...)

I recommend the same.

Ok. I got the wrong impression, then.

And additionally notice that (a) there are cases
when === just useless (and if you don't know what results `typeof` --
that's just your problem) and (b) in language with dynamic type
conversion, == is an additional syntactic sugar for convenience.

Often an inconvenience, it seems...

(...)
You may write on static language. Because I soon (some paranoiacs) will
first freeze their objects (and I know that in committee there are many
people who want to freeze by default all built-in prototypes and
constructors; and the next stage maybe -- static typing and excluding
first-class objects -- yeah, let's make another Java with that long
names and manual everything).

There may be good reasons for wanting that (to freeze). I hope we
don't end up with anything like Java, though.

AIUI they want to find a way for different programs from different
sources to be able to coexist safely in the same JS context under
mutual suspicion, in order to be able to mashup. But while they can
attempt to fix the JS side of things, they can't fix the DOM side of
things, so... <shrug> ¿? </shrug>

 

[Asen Bozhilov]

You may write on static language. Because I soon (some paranoiacs) will
first freeze their objects

Already discovered by google as good practice. See presentation about
changes at the language.
<URL:

>

| Changes to JavaScript, Part 1: EcmaScript 5

That title is broken in first place. The word "change" in such a
context is association with breaking backward compatibility.
"Improvements" is significant better than "Changes".

The interesting parts are after 23rd minute. The are trying to fix the
follow "problem":

function Point(x, y) {
this.x = +x;
this.y = +y;
}

var pt = new Point(6, 3);
/*Clobbers pt's consistency*/
pt.x = "foo";

So, who would try to do this? If someone wants to shot him self, he is
free to do this. That is not our problem, also is not a problem of
ECMA-262 and is not a problem of google.

(and I know that in committee there are many
people who want to freeze by default all built-in prototypes and
constructors;

This cannot be done. They would break backward compatible and such a
decision would break working of many scripts. There are too many
scripts which augment built-in objects. Also, such a decision would be
in contradiction with their decision about `Object.' API.

 

[Dmitry A. Soshnikov]

I'm not "attempting" anything, seriously: no offense meant.


Ok. I got the wrong impression, then.

I'll see, maybe I'll mention some cases explicitly, sort of: "this note
isn't an appeal for everyone to use == when it can be used and bother
yourself and remember much all the ambiguous cases, but to show that
there are completely safe cases when usage of === is strange and that
you should not afraid of == operator". I don't know how exactly to form
this sentence, but I'll add it.

Often an inconvenience, it seems...

Yeah, maybe. But what about exactly you -- when you type in the code
`typeof` and comparing it with a string -- why do you use ===?
Objectively. For consistency? Or what?

If you answer "I don't even think about it, I just write ===" -- this
will be also a good answer because as I said, all languages should be
designed so, that a programmer need not think much (or even at all) on
some auxiliary construction such as ==.

I considered this case and think the same. Just completely obvious and
explicit cases such as `typeof` seems strange in such cases -- just like
people do not think about it not because of the good abstraction, but
because of just simply don't think, because some authority said "use
===". That's worry me and nothing else. And I showed that there is
nothing scary in completely safe-cases and you may use == when you deal
with such cases -- and of them is `typeop`.

Additionally (and objectively) I could even accept avoiding dynamic type
casting at the core of the language. E.g. as Python did (I notice,
Python also have frozen default classes) and you need to use manual casting:

1 == "1" # False
str(1) == "1" # True

But since we haven't it, yeah it's a good advise to avoid ambiguities
(who argue? I recommend the same). But some oblivious safe case (which
looks just ridiculous with using === because many programmers think that
=== is something different and cooler than evil ==) -- on that just I
point. And show that they are the same but not different.

And regarding practical application, I recommend the same: if you need
to consider the type or identity -- use always ===. In all other cases,
== is enough and even can be useful sugar. At the same time, it can be
"evil" sugar, yes.

There may be good reasons for wanting that (to freeze). I hope we
don't end up with anything like Java, though.

AIUI they want to find a way for different programs from different
sources to be able to coexist safely in the same JS context under
mutual suspicion, in order to be able to mashup.

Yes, I know that this is the reason. But for the local project without
several 3rd-party libs, augmenting (again, in dynamic language with
mutable objects) is convenient.

But while they can
attempt to fix the JS side of things, they can't fix the DOM side of
things, so...<shrug> ¿?</shrug>

Yeah, seems so.

Dmitry.

 

[Evertjan.]

Ry Nohryb wrote on 28 jun 2010 in comp.lang.javascript:

d.

Hi Evertjan. There's no adoration over here, nor any heros.

But it happens that most of the times there's a good reason to laugh
at the people that love to nitpck in Crockford's words in an attempt
to look clever, as in writing a long-winded page just to say that
"there are safe-cases, when == isn't (a) "bad" and "evil" part of the
ES", IOW, just to say that a typeof x == "" is functionally identical
to a typeof x === "". Yeah, right, what's the point in that if not to
nitpick his words ?

That could very well be but that is not what I interpreted from you said:

which sounds to me that they are not heeding his "flawless" advice,
adoration indeed.

His advice is simple and flawless: use of (strict comparison
operators) ===/!== is always preferred because ==/!= do type coercion
and this can mask type errors.

No, you would have to do seperate type conversion, which will introduce
the risk of errroring there. Those risks should be assessed first. And
the ease of use you loose is not unimportant.

Errors that are likely in a language
whose vars can hold any type. And face it: you've got to be very lucky
for the mechanisms of type coercion of the ==/!= operators to suit
your particular needs, in any case. So... you're better off typing
explicitly and unequivocally what you want to check for, using the
===/!== operators instead.

But that is not true as his advice introduces other erroring risk.

Javascript is a weak typed language, using it a a strong typed language
because that is what you prefer, is ofcourse allowed, though a bit silly,
as why choose a weak typed language in the first place..

Advertizing it as the ultimum remedium is like advising people to walk
and swim from Amsterdam to New York, with the flawless argument that you
cannot crash due to multiple jet engine failure.

btw, I advice not to use Jet.OLEDB.4.0 engines anymore,
but go for ACE.OLEDB.12.0.