typeof null

Brendan Eich brendan at mozilla.org
Wed May 9 15:55:38 PDT 2012

Jorge wrote:
> On May 9, 2012, at 11:43 PM, Brendan Eich wrote:
>> I think we should consider Object.isObject just because the typeof null change replaced it, but 1JS killed that replacement. Also gives Object.isValue and Array.isArray some company ;-).
> Why not .isPrimitive()?

Could do that too, but Object.isPrimitive(x) would just be 

>   We've always been talking about primitive values and objects, isn't it?

Indeed, sometimes also with "reference type" for objects (not to be 
confused with ECMA-262's "Reference" internal type).

> Are we going to have RegExp.isRegExp() and Date.isDate() and Number.isNumber() etc. too ?

I did wince a bit about ES5's Array.isArray -- perhaps since it takes 
any x and tells whether x is an Array (from any window or frame) 
instance, it should have gone on object. You're right that the 
instanceof limitation motivating Array.isArray applies to these and 
other built-in "classes" as well.

Do we just add 'em all, or try to add only the ones for which we have 
enough experience to hope we're actually helping developers? How many 
times have you wanted RegExp.isRegExp, say? The belief is that testing 
for array-ness is more common. I don't have data, though, so I'm 
uncomfortable with any "need-based" approach.

Adding lots of predicates is straightforward, but then the dialectic 
requires us to wince at the sheer number of predicates (and the 
redundant name stems), and try for something like what Axel suggested: a 
do-it-all "type" or "typeOf" or "classify" API.

Comments welcome. I'm not sure what is best but lean toward predicates 
as goods in themselves, even if not the complete solution (if there is a 
complete solution).


More information about the es-discuss mailing list