Prev: Microsoft's ECMAScript Test Suite
Next: JS charting library that can do bar charts from series of time "mm:ss" strings?
From: Dmitry A. Soshnikov on 25 Jun 2010 16:36
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.
From: VK on 26 Jun 2010 07:07
On Jun 26, 12:36 am, "Dmitry A. Soshnikov"
<dmitry.soshni...(a)gmail.com> wrote:
> 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.
From: Dmitry A. Soshnikov on 26 Jun 2010 11:33
On 26.06.2010 15:07, VK wrote:
> On Jun 26, 12:36 am, "Dmitry A. Soshnikov"
> <dmitry.soshni...(a)gmail.com> wrote:
>> 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".
>

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.
From: Dmitry A. Soshnikov on 26 Jun 2010 11:36
On 26.06.2010 15:07, VK wrote:

<snip>

>
> 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.
From: VK on 26 Jun 2010 12:38
On Jun 26, 7:36 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
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.

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.
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Microsoft's ECMAScript Test Suite
Next: JS charting library that can do bar charts from series of time "mm:ss" strings?