typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Brendan Eich]

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 
what

http://wiki.ecmascript.org/doku.php?id=strawman:value_objects

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.

/be