typeof null

Brendan Eich brendan at mozilla.org
Tue May 8 18:07:20 PDT 2012

Axel Rauschmayer wrote:
>> Constants? We don't need no stinking constants! :-P Manifest strings, 
>> a la typeof, are the natural and self-describing upgrade path, if 
>> we're talking typeof (see Subject).
>> The Reflect namespace object is part of direct proxies, also 
>> populated in SpiderMonkey (not web-facing) by Reflect.parse to get an 
>> AST for a given source string. We could indeed put type-reflecting 
>> method(s) there but I'm loath to add manifest constants. What's wrong 
>> with strings?
> Nothing – if it’s only about primitive values. But if you want to have 
> something that is both Allen’s `class` operator (for objects) and 
> `typeof` (for primitive values) then constants are the best solution 
> (that I can think of). I’ve always thought that the distinction 
> between typeof and instanceof was a bit artificial, it would be nice 
> if we had something that unified both.

The problem with constants is that users have to manage a closed (by ES 
version) manifest constant set. Polyfilling can't necessarily extend the 
Reflect constants (or can it? But then what's the advantage over strings?).

Unifying object [[Class]] with typeof -type can be done via strings too. 
The problem remains the closed set of constants.

> Or do you propose returning functions for objects and strings for 
> primitives? E.g.:
> switch(type(x)) {
>     case "null":  // x is null
>         ...
>         break;
>     case "string":  // typeof x === "string"
>         ...
>         break;
>     case String:  // x instanceof String
>         ...
>         break;
> }

No. I would rather an upgrade for typeof, than something that tries to 
do two different things under one API.

Object class reflection is frowned upon in Smalltalk for a reason. We 
want protocols, structural conventions -- not nominal type tags. Or so I 


More information about the es-discuss mailing list