Note 2. ECMAScript. Equality operators.
Dmitry A. Soshnikov
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
<dmitry.soshni...@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."
>
>
> 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
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
<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.
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.
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
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
<snip>
> "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
wrote:
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.
Stefan Weiss
> 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.
Where did you get that idea?
"\u00e4" // ä
"\u0061\u0308" // ä
"\u00e4" == "\u0061\u0308" // false
"\u00e4" === "\u0061\u0308" // false
"\u00e4" > "\u0061\u0308" // true
"\u00e4" < "\u0061\u0308" // false
If you want to confirm this with the actual characters in a string
literal instead of \u escapes, try this:
http://foo.at/paste/2010/test.diaresis.html
--
stefan
Dmitry A. Soshnikov
<snip>
> 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
<dmitry.soshni...@gmail.com> wrote:
> (...)
> 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
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.
--
Jorge.
Dmitry A. Soshnikov
> On Jun 27, 11:00 pm, "Dmitry A. Soshnikov"
> <dmitry.soshni...@gmail.com> wrote:
>> (...)
>> 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 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.
> 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.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Ry Nohryb
wrote:
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.
--
Jorge.
Ry Nohryb
wrote:
> (...)
> 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 :-)
--
Jorge.
Dmitry A. Soshnikov
> 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
> On Jun 28, 9:38 am, "Dmitry A. Soshnikov"<dmitry.soshni...@gmail.com>
> wrote:
>> (...)
>> Yeah, funny demagogy ;) Don't worry, I have immunity for it.
>> (...)
>
> 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
wrote:
> On 28.06.2010 16:20, Ry Nohryb wrote:
> 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.
> (...)
> > 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.
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>
--
Jorge.
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: http://www.youtube.com/watch?v=Kq4FpMe6cRs >
| 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
> On Jun 28, 3:05 pm, "Dmitry A. Soshnikov"<dmitry.soshni...@gmail.com>
> wrote:
>> On 28.06.2010 16:20, Ry Nohryb wrote:
>>> (...)
>> 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.
>
>> (...)
>>> 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.
>
> 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.
>> 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...
>
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.
>> (...)
>> 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.
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.
>> 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
>> discourage
> 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 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 ?
That could very well be but that is not what I interpreted from you said:
> > 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.
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.
Dmitry A. Soshnikov
I've updated:
"And this note isn't an appeal for everyone to use == when it's can be
used and to bother yourself with remembering all the ambiguous cases
related to implicit type conversion, of course not. However, here 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. These cases are <em>completely safe</em>, related to the
<em>standard behavior and algorithms</em> of the ECMA-262 specification
and usage of === with them can look a bit strange. Let's see it on the
example."
So, is it more "politically correct" now?
Dmitry.
Dmitry A. Soshnikov
> Dmitry A. Soshnikov wrote:
>
>> 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: http://www.youtube.com/watch?v=Kq4FpMe6cRs>
>
Yes, I saw this lecture before of course. Generally, the lecture is good
(as an overview), M.Miller just explains the ability but not force to do
this.
But the another topic -- to "freeze & strict everything" - yeah, very
debatable.
> | 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.
>
Yes, I think this is again explained from the position of a user which
plays in his sandbox (a web-page) and change everything and all via
console or "javascript:" pseudo-protocol. Will a programmer do this? To
break his code -- very debatable.
>> (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.
Yes, of course. As I remember, Brendan Eich don't wanna this (freezing
built-ins) too.
As I told (and my position still the same): misconception is not to
augment built-ins (in a local project with avoiding consequences), but
misconception is to have mutable non-frozen built-ins and call as a
misconception their augmentation. I told -- if this is a misconception
-- just do it more radically, as Python did -- just "freeze them all"
that programmers have no temptation to do this. On what the reply was --
<https://mail.mozilla.org/pipermail/es-discuss/2010-April/010973.html>.
So, of course it won't be done, at least soon, by several reasons.
Dmitry.
nick
> when you type in the code
> `typeof` and comparing it with a string -- why do you use ===?
> Objectively. For consistency? Or what?
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. The
whole thing sounds like a stylistic issue to me; the functionality of
the two operators in the case of typeof is basically identical as
discussed here ad nauseum.
Dmitry A. Soshnikov
>
>> when you type in the code
>> `typeof` and comparing it with a string -- why do you use ===?
>> Objectively. For consistency? Or what?
>
> 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.
Dmitry A. Soshnikov
<snip>
>
> 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.
>
<snip>
>
> 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".
<snip>
>
> 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.
>
Done. Now I like it more. I should admit that the previous version was
the worst my article -- objectively. Because it was too emotional, but
not analytic.
After corrections, it's much better:
<http://dmitrysoshnikov.com/ecmascript/note-2-ecmascript-equality-operators/>
Thanks all, especially VK, Jorge and nick.
Dmitry.