関数の名前はisNaN
意味的に value を参照しますisNaN
が、ネイティブ実装はorのようなtrue
一部の非NaN
オブジェクトを返します。undefined
{}
isNaN(undefined);
=> true
たとえば、アンダースコアの実装ははるかに直感的/論理的だと思います。
_.isNaN(undefined);
=> false
ECMA 標準がこのような直感に反する動作を指定したのはなぜですか?
テストする値が
本当にある場合にのみisNaN
返されるように設計し、別の関数で数値への変換可能性をテストする負担を残すように設計しなかったのはなぜですか?true
isNaN
isNumber
このようにすると、数値をテストするときに二重否定がないなど、さらに多くの利点が得られます。
if (isNumber(x)) { } // if x is a number
それ以外の
if (!isNaN(x)) { } // if x is not not a number
ECMAScript 6 で導入する予定なのでNumber.isNaN()
(期待どおりの動作をします)、このように考える人が増えているようです。
では、なぜ彼らisNaN
はそもそもこのようなデザインをしたのでしょうか? それは単に間違った決定でしたか、それともそうする正当な理由がありましたか?