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: Ry Nohryb on 27 Jun 2010 19:07 On Jun 27, 11:00 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)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 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.
From: Dmitry A. Soshnikov on 28 Jun 2010 03:38 On 28.06.2010 3:07, Ry Nohryb wrote: > On Jun 27, 11:00 pm, "Dmitry A. Soshnikov" > <dmitry.soshni...(a)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.
From: Evertjan. on 28 Jun 2010 05:50 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. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Ry Nohryb on 28 Jun 2010 08:20 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 ? 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.
From: Ry Nohryb on 28 Jun 2010 09:04
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). However you're free to continue with the new sport: nitpicking him :-) -- Jorge. |