typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Axel Rauschmayer axel at rauschma.de
Mon Oct 1 14:17:49 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.

Internally, probably not, because primitives are fundamentally different. But what the user is seeing is different. I’ve used JavaScript for years, without knowing about the difference. And one often reads “everything is an object in JavaScript” on the web, because the illusion is really quite well maintained (*except* for typeof vs. instanceof).

But “a better instanceof” is something that can be prototyped as a library function. I’ll do so and will also try to figure out what the actual use cases for typeof/instanceof are – this kind of categorization is indeed a bit of an anti-pattern (I think Allen pointed that out recently).

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

That would be nice as a complementary measure. Especially "null" would be great, but it seems like a risky change. Having both "object" and "function" is something that’s unfortunate, but unfixable.

> 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 cross-frame.

Right, sorry for conflating two issues. My main point was: any kind of simplification of the current situation helps (even typeof o === "null" which, OTOH, might not be worth the risk).

Regarding cross-frame: Many explanations on the web of determining whether a value is an array sound like this is an impossible task (ignoring Array.isArray()) and that’s a shame. Alas, I’m not sure how one could do better here, it’s really a tricky problem. postMessage seems like a partial solution.

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

I agree. typeof should (at most) be slightly updated to keep up with changes and to become less quirky.

Axel

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121001/a7de5597/attachment.html>


More information about the es-discuss mailing list