Agreed. Although benchmarking performance, in my opinion, is more of a study than a programming advantage. It's to affirm that a model does indeed work without flooding the system with memory intensive operations. The goodness an inheritance model brings has more to do with simplifying code rather than performance.
This is a follow up to a previous post "Null and typeof" (http://kiro.me/blog/typeof_null.html). Here, the NaN definition and implementation is explained.
"I think it's only bad because it would break with future changes to typeof"
You're completely right.
The proposal (http://wiki.ecmascript.org/doku.php?id=proposals:typeof) suggests the change of typeof null to actually return "null"; however, as Douglas Crockford points out, "existing code cannot anticipate the change". Additionally, Brendan Eich states that "neither this proposal nor the bug fixes in that proposal are backward-compatible".
Indeed. That's because ECMAScript standard states that Numbers should be IEEE-754 floating point data, which includes positive and negative infinity, and also NaN. Hence why, in JS, it's part of the Number object: Number.NaN. Technically, it's stil a numeric data type, but just points to an invalid number :)
