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).
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
