Hacker News new | past | comments | ask | show | jobs | submit login
JavaScript - "typeof" operator & null (kiro.me)
36 points by krisk on June 21, 2012 | hide | past | favorite | 12 comments



Another fun typeof quirk that the table leaves out:

Regular Expressions, depending on the V8 or Nitro engine version, are implemented to return either 'object' or 'function' http://bonsaiden.github.com/JavaScript-Garden/#types.typeof

Recent versions of V8 and Nitro return 'object' now, but presumably, there are many people still running browsers that return 'function'.

Seems like it relies on whether or not the RegExp is callable, but that the 2 engines removed 'function' as they ceased supporting callable RegExes. http://code.google.com/p/v8/issues/detail?id=617


I often use the improved typeof function: http://javascriptweblog.wordpress.com/2011/08/08/fixing-the-...

Question: why is the way to determine null considered "very bad"? It works and seems like a valid way, since both empty objects and arrays are truthy, null is the only falsy "object" type.


I think it's only bad because it would break with future changes to typeof. Of course I may be completely wrong on that.

This works just as well and is more future proof though:

    function isNull(x) { return x === null }
At which point you don't really need a function at all. Perhaps the version using typeof is from a time when there was no === operator. Was that pre-ES3? I think so but am not certain.


"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".


Oh yeah, of course. There's no need when you can just do === null.


The other gotcha with "typeof": "typeof NaN" is "number", amusingly enough.


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


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


My biggest WTF was when I discovered that parseFloat("Infinity") returns... Infinity itself.

I was working on a site that dealt with English dictionaries, and had a field where you could enter either an English word, OR a number with decimals that represented its frequency. And one day I actually typed in "Infinity" as a test word, and program execution went down a completely unexpected code path... Probably the most surprised I've ever been by a bug.


You may want to mention the language that you are talking about in future titles.


True. Thanks!


There, updated.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: