Rationale for why ECMAScript converts primitive values to numbers in == operator comparisons when one is boolean

Brendan Eich brendan at mozilla.com
Sun Jan 6 15:05:44 PST 2013

Brendan Eich wrote:
> The bias toward comparing strings as numbers if either operand is a 
> number or a boolean stems from the HTTP header and numeric-string HTML 
> form field use-cases. Not good reasons, again, but that's how JS 
> "works" :-|. 

One more note: it could be argued that narrowing from string to number 
would be ok (as in, useful most of the time, and not unsafe) if any 
non-numeric, non-empty string-to-number implicit conversion attempt 
threw an exception.

Here's where another path-dependent bias in JS's design bit: no 
try/catch in JS1 or any ECMA-262 standard till ES3.

The lack of exception handling also meant undefined is imputed for 
missing obj.foo property get where obj has no such property. That is 
still biting back, perhaps as much as or more than implicit conversions 
bite ==. It is also the basis of web JS's winning "object detection" 
pattern, which fairly beats all other versioning schemes I've seen, 
especially a-priori ones based on explicit numbering and opt-in.

If only I'd taken the time to add an existential operator for object 
detection, so one could write

   function emulateRequestAnimationFrame(...) {...}
   if (!window.requestAnimationFrame?)
     window.requestAnimationFrame = emulateRequestAnimationFrame;

IOW, if only I'd made window.noSuchProperty throw but 
window.noSuchProperty? evaluate to truthy or false (details still TBD, 
see the "fail-fast object destructuring" thread revival, the Nil idea).


More information about the es-discuss mailing list