typeof symbol (Was: Sept 19 TC39 Meeting Notes)
brendan at mozilla.org
Sat Sep 29 18:25:55 PDT 2012
Uli Riehm wrote:
> It’s bad... but ways better than typeof. I don’t think typeof should
> be extended, it always returned lower cased names and not the upper
> cased string,
No one is proposing that typeof return capitalized strings or anything
that might be a constructor name in a global object.
The invariant I gave,
(typeof x == typeof y && x == y) <=> x === y
helps keep typeof, == and === saner than otherwise. My argument builds
on it by observing (independent observation) that users will expect 0L
== 0UL but 0L !== 0UL. If that's true, then typeof 0L != typeof 0UL in
order for the left-to-right implication direction to hold.
That means typeof 0L and typeof 0UL can' t both be "object", in spite of
says. The simplest and clearest solution is to extend typeof so typeof
0L is "int64" and typeof 0UL is "uint64".
Programmers still use typeof heavily, much more than instanceof. The
idea that it should not be extended on principle does not hold up, since
IE has already done so, and more primitive relations in the language
(the <=> invariant above) seem to require typeof extension, and it has
been on our agenda for value types or value objects.
So arguing "It's bad... but way better than typeof" based on a sense of
smell is not enough. We need to reason from the invariant relations
among operators in the language.
More information about the es-discuss