typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Brendan Eich brendan at mozilla.com
Mon Oct 1 13:01:41 PDT 2012

Herby Vojčík wrote:
> Brendan Eich wrote:
>> 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.
> As I read it (and as I see it), there was not a call for folding the 
> two into one. I see it as a call to "institutionalize" the de-facto 
> status quo, where typeof distinguishes between objects ("object" and 
> "function") and primitives/atoms (everything else), while 
> primitives/atoms are 2nd-level-distinguished among themselves by the 
> actual typeof value (objects do not, they use instanceof or other 
> means to do it).

Axel wrote

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

and he is right, but the complaints there come from instanceof failing 

typeof works cross-frame.

But this does not mean extending typeof to distinguish within 
non-function objects.

> If this is the case, it implicitly means that if new type of primitive 
> is added to the language, it gets its typeof tag; but the realm of 
> true objects is not harmed in any way.

We agree on this, but I think Axel is right to lament the cross-frame 
problem with instanceof, which begat Array.isArray.

Just to repeat, and I'm not sure where Axel stands on this: extending 
typeof does not make this problem worse. But I do not see a way to 
extend typeof to solve the cross-frame object classification problem.


More information about the es-discuss mailing list