typeof symbol (Was: Sept 19 TC39 Meeting Notes)
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.
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.
Dr. Axel Rauschmayer
axel at rauschma.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss