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 27 Jun 2010 07:35 On 26.06.2010 20:38, VK wrote: > 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. 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.
From: Dmitry A. Soshnikov on 27 Jun 2010 08:32 On 26.06.2010 20:38, VK wrote: <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.
From: VK on 27 Jun 2010 15:37 On Jun 27, 4:32 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 26.06.2010 20:38, VK wrote: > > <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. 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.
From: Stefan Weiss on 27 Jun 2010 16:38 On 27/06/10 21:37, VK wrote: > 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
From: Dmitry A. Soshnikov on 27 Jun 2010 17:00
On 27.06.2010 23:37, VK wrote: <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. |