Mark S. Miller wrote:
I am uncomfortable expanding the typeof namespace. Where do these new
names come from, and how do we avoid collision?
You still value the
(x == y && typeof x == y) <=> x === y
invariant, right? That's the motivation for decimal, int64, etc. having
their constructor-named "decimal", "int64", etc., typeof-result strings.
We decide these for ES7 for sure, since we're considering value objects
for important machine and user-wanted types (int64, bignum).
We also agreed, in deferring decimal (late for ES5 anyway), that it
should happen via self-hosted "user code". You and I discussed
up-thread, and I'm going to write a strawman for operators and literals.
Suffice to say here that such user-defined value objects should enable
typeof-result customization. There could be conflicts, just as literals'
suffixes could conflict. This is not a deal-breaker, and I should work
on that strawman before we over-rotate on it. But can we agree here that
we're trying not to hardcode value objects in future editions, rather
cover the important machine and user-facing types and support
self-hosting, and let library authors extend the system rather than TC39?
Note also that IE JScript has non-standard typeof-results, and this gave
us hope (when we last discussed it) that we too could extend typeof's
codomain.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
