krisk

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.

I've written another post which explores NaN in detail: "NaN and typeof" - http://kiro.me/blog/typeof_nan.html

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 :)

There, updated.

True. Thanks!

Dammit. The link is supposed to be: http://kiro.me/projects/fuse.html

Totally my bad. It's http://kiro.me/blog/nfe_dilemma.html

Well, this is embarrassing. Yes, the link is http://kiro.me/blog/nfe_dilemma.html