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: Dmitry A. Soshnikov on 28 Jun 2010 09:05 On 28.06.2010 16:20, Ry Nohryb wrote: > On Jun 28, 11:50 am, "Evertjan."<exjxw.hannivo...(a)interxnl.net> > wrote: >> 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.
From: Dmitry A. Soshnikov on 28 Jun 2010 09:12 On 28.06.2010 17:04, Ry Nohryb wrote: > On Jun 28, 9:38 am, "Dmitry A. Soshnikov"<dmitry.soshni...(a)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.
From: Ry Nohryb on 28 Jun 2010 09:56 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. > 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.
From: Asen Bozhilov on 28 Jun 2010 10:23 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 > | 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.
From: Dmitry A. Soshnikov on 28 Jun 2010 10:28
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. >> 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. |