typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Uli Riehm]

  The simplest and clearest solution is to extend typeof so typeof 
  0L is "int64" and typeof 0UL is "uint64".
If typeof 0L === ‘int64’, then because of it’s string nature typeof 0L !== ‘number’. Isn’t that breaking compatability?

Maybe instanceof could be extended, first as binary operator also working on string (and second as an unary operator returning the final constructor’s global name)?

var i = Int64(0L);

i instanceof ‘Int64’ === i instanceof Int64 // true
i instanceof ‘Number’ === i instanceof Number // true
// i instanceof ‘Object’ // true?

instanceof i === ‘Int64’ // unary returning final constructor’s name (for re-expression)

The typeof operator always issues an equal operator, so you can’t say an int64 is also a number. Isn’t it? I believe typeof should think it’s a number (like NaN or Infinity), only something more detailed knows that it is an Int64 Number. Maybe 0L is not an Object - for this I also like the post of Axel Rauschmayer, where he proposes a ValueType function. instanceof could say it’s not Object, but it is an ValueType instead. For example 0L instanceof Int64 Number ValueType and (new Int64(0L)) instanceof Int64 Number Object.

Uli
http://metadea.de/V/

-----Ursprüngliche Nachricht----- 
From: Brendan Eich 
Sent: Sunday, September 30, 2012 3:25 AM 
To: Uli Riehm 
Cc: es-discuss 
Subject: Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes) 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120930/53001a34/attachment.html>