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.
My position remains that we should leave instanceof alone and extend
typeof where the relations we want to preserve require it.
/be
Axel Rauschmayer wrote:
However, this clearly is an issue beyond symbols alone. The same
problem re-arises whenever we have to add new primitive types in the
future. It doesn't seem like a sustainable strategy to fake any new
type ever into an object. Perhaps it is less harmful on the long run
if we took the chance to clarify _now_ that the set of strings
returned by 'typeof' is not fixed, and should not be treated as such?
It would be great if there was a consistent vision as to where
categorization of values should be headed:
What do we need? What is categorization currently used for in
practice? How can we achieve it in a future-friendly way? How can we
simplify things, long term?
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.
ECMAScript.next is shaping up to be a nice and clean language, except
for this one area.
--
Dr. Axel Rauschmayer
[email protected] <mailto:[email protected]>
home: rauschma.de <http://rauschma.de>
twitter: twitter.com/rauschma <http://twitter.com/rauschma>
blog: 2ality.com <http://2ality.com>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
