typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Brendan Eich brendan at mozilla.com
Mon Oct 1 12:43:50 PDT 2012

It's a mistake to mix up the two-level distinction in JS, though. 
Backward compatibility and the ==/=== invariant require typeof to 
classify a certain way that cannot capture instanceof. You can't fold 
the two into one.

My position remains that we should leave instanceof alone and extend 
typeof where the relations we want to preserve require it.


Axel Rauschmayer wrote:
>> However, this clearly is an issue beyond symbols alone. The same
>> problem re-arises whenever we have to add new primitive types in the
>> future. It doesn't seem like a sustainable strategy to fake any new
>> type ever into an object. Perhaps it is less harmful on the long run
>> if we took the chance to clarify _now_ that the set of strings
>> returned by 'typeof' is not fixed, and should not be treated as such?
> It would be great if there was a consistent vision as to where 
> categorization of values should be headed:
> What do we need? What is categorization currently used for in 
> practice? How can we achieve it in a future-friendly way? How can we 
> simplify things, long term?
> At the moment, things are a mess (between typeof, instanceof, 
> [[Class]], Array.isArray, cross-frame communication, etc.). And I 
> wouldn’t want that mess to get even worse.
> ECMAScript.next is shaping up to be a nice and clean language, except 
> for this one area.
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
> home: rauschma.de <http://rauschma.de>
> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
> blog: 2ality.com <http://2ality.com>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list