Note 2. ECMAScript. Equality operators.
in [JavaScript]
|
Prev: Microsoft's ECMAScript Test Suite
Next: JS charting library that can do bar charts from series of time "mm:ss" strings?
From: Evertjan. on 28 Jun 2010 10:57 Ry Nohryb wrote on 28 jun 2010 in comp.lang.javascript: >> 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. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Dmitry A. Soshnikov on 28 Jun 2010 14:10 On 28.06.2010 18:28, Dmitry A. Soshnikov wrote: > On 28.06.2010 17:56, Ry Nohryb wrote: >> On Jun 28, 3:05 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)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. > 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.
From: Dmitry A. Soshnikov on 28 Jun 2010 14:39 On 28.06.2010 18:23, Asen Bozhilov wrote: > 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.
From: nick on 28 Jun 2010 15:45 > 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.
From: Dmitry A. Soshnikov on 29 Jun 2010 04:18
On 28.06.2010 23:45, nick wrote: > >> 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. |