typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Herby Vojčík herby at mailbox.sk
Sat Sep 29 13:44:07 PDT 2012

Brendan Eich wrote:
> Herby Vojčík wrote:
>> - closer to object === "symbol have its own identity, state and
>> behaviour, I can add new properties and methods etc." (an array is
>> good example of this, if you consider what it can do _beyond_ elements
>> and length)
>> - close to string === "symbol have its own identity and a little more
>> than that"
>> IOW, it seems to me that symbols are more like "parallel" set of
>> strings, of which every new one is different ("has different sequence
>> of chars"), but it does not carry all the other "object-like" traits
>> with it.
> That still leaves open the possibility that someone could forge a string
> equal to the symbol, which is not possible.
>> More or less, only things that matters if if a symbol a === a symbol
>> b. Which I see as string-like, not an object-like.
> No, symbols are not strings.

No, they're not, of-course. I'd say they string-like (more than 

If you say strings have content and are forgeable, that shows that what 
I wanted to say, is something slightly different. Basically I wanted to 
say that such entities (where identity is only thing they have; which 
seemed for me closer to string than to object) are "atoms" (maybe they 
can have typeof "atom" with future possibility to use it for other such 
beasts, if they occur beyond symbols).

But OTOH, all primitives are "atoms" in this view (strings, too). The 
only difference is, if they are forgeable (that is, I can produce them 
by some operations, like +, from their peers). If fact, I don't see this 
as distiguishing property enough. The nature of "I hold no subvalues, my 
identity is my value" is what separates primitives from objects (or 
maybe not primitives, but atoms, and primitives <= atoms), not the 

So, symbols look to me more like primitives/atoms (that means, not an 
object nor function) and so they should have their own typeof...

> * You can't forge a symbol, but you can easily make up any string, with
> some effort brute-force-attack a secret string, etc.
> * Symbols do not get auto-wrapped by String wrappers (or appear to be
> auto-wrapped) such that String.prototype methods work.
> I agree with Tom, "object" is the best choice if we are to avoid
> extending typeof's codomain. If we choose to extend, then your best case
> made above arguess for "symbol", not "string".
> /be


More information about the es-discuss mailing list