>> 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).
>
> We can't change typeof null === "null". V8 tried and it broke the web, and
> 1JS means we do not want typeof changing rules under module {...} -- that's a
> gratuitous refactoring hazard.
>
> typeof (function(){}) == "function" && typeof null == "object" && typeof {}
> == "object" -- just grieve and accept! I have :-P. Doesn't mean typeof is not
> useful and indeed widely used, and important for the ==/=== two-way
> implication. Other type tests would work for that implication, but typeof is
> the one in the language.
I agree, sorry for not having been clearer – that’s what I meant by “ might not
be worth the risk”. But it seems to have come up again as a possibility in this
thread.
>> 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.
>
> Or Object.prototype.toString.call(x).slice(8, -1) === "Array"? Not iron-clad
> but prior to Array.isArray, nothing is.
Yes, but yet another special case: “use typeof (along with === and !==), except
where you have to use instanceof, except where you have to access [[Class]] in
a non-obvious manner”.
I’m not complaining, merely suggesting that there must be a better way. But
I’ll offer something concrete by writing up a few thoughts.
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
