typeof symbol (Was: Sept 19 TC39 Meeting Notes)
brendan at mozilla.org
Sat Sep 29 11:42:41 PDT 2012
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.
* 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".
More information about the es-discuss