The strange story of ! and ==(=)false
in [JavaScript]
|
Prev: Number list to display in the slide show
Next: FAQ Topic - How do I prompt a "Save As" dialog for an accepted mime type? (2010-06-27)
From: VK on 26 Jun 2010 11:59 On Jun 26, 6:48 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote: > I don't think that is enough for me, Stefan. > > (x ==false) returns a boolean based on x after conversion to a boolean. It is not what ('000' == false) exactly does: it first attempts to treat '000' as a string representation of a number literal. '000' for JavaScript is a valid literal of octal 0. If the first step succeeded - and it did - then any non-zero value is treated as true and 0 as false for logical comparison contexts. Therefore the initial statement comes to (false == false) and it's definitely true. There are programming languages with an opposite approach, say in Perl any string with length>=2 will be treated as true. What is more logical depends on a particular taste. > (! x) should do exactly the same. Not at all. It first creates new Boolean from '000', where if the argument is omitted, or is false, 0, null, NaN, or an empty string, the initial value is false; otherwise, the initial value is true. Therefore the result for '000' is true. Then it applies NOT to the current Boolean value, so the result is false. I don't know (neither I do care) what "ECMAScript" does but JavaScript does exactly that for the last 12 years at least (checked on NN 3.0 Gold out of my pure curiosity).
From: Stefan Weiss on 26 Jun 2010 13:01 On 26/06/10 17:59, VK wrote: > On Jun 26, 6:48 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote: >> (x ==false) returns a boolean based on x after conversion to a boolean. > > It is not what ('000' == false) exactly does: it first attempts to > treat '000' as a string representation of a number literal. '000' for > JavaScript is a valid literal of octal 0. If that was all there was to it, then "004" == "4" would also need to be true. > If the first step succeeded - and it did - then any non-zero value is > treated as true and 0 as false for logical comparison contexts. > Therefore the initial statement comes to (false == false) and it's > definitely true. This explanation is not correct. According to you, "002" == true should return true. Let's try it out: "001" == true; // true "002" == true; // false If you leave out the step of converting the right hand side of the comparison to a numeric value, you can't explain these results. > There are programming languages with an opposite approach, say in Perl > any string with length>=2 will be treated as true. What is more > logical depends on a particular taste. That's very misleading. First of all, Perl doesn't have a boolean type at all, so the analogy with our JavaScript comparison example is rather pointless. Second, in contrast to other scripting languages like JS and PHP, Perl managed to get the difference between numeric and string comparisons right - it uses different operators for the two. (It also has different operators for numeric addition and string concatenation, another common source for errors in JS and PHP). And most puzzling, whatever did you mean with "any string with length>=2 will be treated as true"? Did you mean to imply that strings of less than two characters evaluate to false? All strings evaluate to true in Perl, with "0" and the empty string as the only exceptions. What you wrote is technically correct, but about as helpful as saying "in Perl, any string starting with 'VK' is treated as true". Perl also handles the string "0 but false" specially, but that's getting a little off-topic. >> (! x) should do exactly the same. > > Not at all. It first creates new Boolean from '000', [...] No, it doesn't. There are no Boolean objects involved in this operation. > where if the > argument is omitted, or is false, 0, null, NaN, or an empty string, > the initial value is false; [...] Add the undefined value to that list. > I don't know (neither I do care) what "ECMAScript" does but JavaScript > does exactly that for the last 12 years at least (checked on NN 3.0 > Gold out of my pure curiosity). That's nice and all, but your explanation is still incorrect. -- stefan
From: VK on 26 Jun 2010 13:24 On Jun 26, 9:01 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: > > It is not what ('000' == false) exactly does: it first attempts to > > treat '000' as a string representation of a number literal. '000' for > > JavaScript is a valid literal of octal 0. > > If that was all there was to it, then "004" == "4" would also need to be > true. From what sky blue? String comparison goes by absolutely different rules. Would you also claim that ("2+2" == "4") // should be true as well? :-)) If still any doubts then try say ('0x0' == false) // true > > If the first step succeeded - and it did - then any non-zero value is > > treated as true and 0 as false for logical comparison contexts. > > Therefore the initial statement comes to (false == false) and it's > > definitely true. > > This explanation is not correct. According to you, "002" == true should > return true. Let's try it out: > > "001" == true; // true > "002" == true; // false ('0x0' == false) // true ('0x1' == false) // false ('0x2' == false) // false The non-commutative logic, Sir. :-) Forget about true, work with false only. > >> (! x) should do exactly the same. > > > Not at all. It first creates new Boolean from '000', [...] > > No, it doesn't. There are no Boolean objects involved in this operation. Again, we are not talking about some mysterious "ECMAScript" but about JavaScript this ng is about. In JavaScript this object is heavily involved in they way as described.
From: Stefan Weiss on 26 Jun 2010 13:46 On 26/06/10 19:24, VK wrote: > On Jun 26, 9:01 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: [VK wrote:] >> > It is not what ('000' == false) exactly does: it first attempts to >> > treat '000' as a string representation of a number literal. '000' for >> > JavaScript is a valid literal of octal 0. >> >> If that was all there was to it, then "004" == "4" would also need to be >> true. > > From what sky blue? String comparison goes by absolutely different > rules. My point exactly. How the left side of a non-strict comparison is evaluated depends on the right hand side as well. >> This explanation is not correct. According to you, "002" == true should >> return true. Let's try it out: >> >> "001" == true; // true >> "002" == true; // false > > ('0x0' == false) // true > ('0x1' == false) // false > ('0x2' == false) // false > > The non-commutative logic, Sir. :-) Forget about true, work with false > only. Allow me to repeat my earlier recommendation, sir. Don't use either. >> >> (! x) should do exactly the same. >> >> > Not at all. It first creates new Boolean from '000', [...] >> >> No, it doesn't. There are no Boolean objects involved in this operation. > > Again, we are not talking about some mysterious "ECMAScript" but about > JavaScript this ng is about. In JavaScript this object is heavily > involved in they way as described. Since we're talking about a hypothetical intermediate object, I'll believe that when you can show me the source. The "mysterious ECMAScript" specification doesn't describe the creation of such an object, and I seriously doubt that there are any implementations out there which would create one, just for fun. I could be mistaken, but since it's your claim, the burden of proof is on you. -- stefan
From: VK on 26 Jun 2010 14:22
On Jun 26, 9:46 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: > > ('0x0' == false) // true > > ('0x1' == false) // false > > ('0x2' == false) // false > > > The non-commutative logic, Sir. :-) Forget about true, work with false > > only. > > Allow me to repeat my earlier recommendation, sir. Don't use either. The "right" vs. "wrong" comparison approach summary I expressed to Dimitry http://groups.google.com/group/comp.lang.javascript/msg/7b28e70774742d92 The right one is the one that is right to you in this particular situation, namely what do *you* want to treat as true or false. Let's us not be mixing the boolean logic with the aesthetics and rights and wrongs, good and bad respectively :-) There can be situations when any potential 0 must be false, so you want "0", "0x0" etc. to be false as well. There can be situations where only non-emptiness of string matters. There can be situations when you want false to be true and vice versa (inverse logic). Without knowing that particular project and its purpose no generalized pattern should/can be given. > >> >> (! x) should do exactly the same. > > >> > Not at all. It first creates new Boolean from '000', [...] > > >> No, it doesn't. There are no Boolean objects involved in this operation. > > > Again, we are not talking about some mysterious "ECMAScript" but about > > JavaScript this ng is about. In JavaScript this object is heavily > > involved in they way as described. > > Since we're talking about a hypothetical intermediate object, I'll > believe that when you can show me the source. The "mysterious > ECMAScript" specification doesn't describe the creation of such an > object, and I seriously doubt that there are any implementations out > there which would create one, just for fun. I could be mistaken, but > since it's your claim, the burden of proof is on you. I am saying something and it correlates with the experimental results down to NN 2.02 You are saying something and it doesn't explain the experimental results down to NN 2.02 Who's the burden of proof is? Upcasting and downcasting in JavaScript never were throughoutly documented anywhere, it is a historical inheritance thing in the most of its parts. A good sample is the implicit upcasting/downcasting of string primitives like var s = 'abc'; var l = s.length // here and the "helper" for number primitives like var n = 2; window.alert( (n).toString(2) ); // here - no parenthesis for n = error One need to go to Netscape developers archives via wayback machine, somewhere there I presume. Don't want to spend the week-end on that really. Yet I didn't say "no". |