typeof symbol (Was: Sept 19 TC39 Meeting Notes)
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).
"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
> 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