Eddy Bruel (2013-04-12T22:21:27.000Z)
On 4/13/13 12:12 AM, Brandon Benvie wrote:
> Based on recent discussions, it seems that there's some confusion 
> about what exactly Symbols are. So far I've seen three different 
> alternatives:
>
> 1.) Exotic objects that conform to the most recent ES6 spec, but with 
> a special typeof .That is, they have special operations for all the 
> internal methods. These internal methods make them act as stateless, 
> immutable, prototypeless objects such that they can be treated like 
> primitives. The problem here is introducing new typeof semantics, 
> where something that otherwise acts like an object is not typeof === 
> "object".
>
> 2.) A new type of primitive that have no object wrapper version, thus 
> `ToObject(symbol)` throws. This means either they have to be falsey or 
> a new situation arises where `if (val != null) val.prop` throws 
> (ignoring accessors and proxies).
>
> 3.) A new type of primitive along with a new type of wrapper. In this 
> case we use the String/Number/Boolean precedent where `Symbol()` and 
> `new Symbol()` produce different kinds of results. The problem here is 
> the confusion that comes with ToString/ToPropertyKey when called on a 
> Symbol wrapper. What does `obj[new Symbol] = 5` do, for example? It 
> allows footguns like `obj[key + '_ext']` to silently do the wrong thing.
>
>
> A relevant gist here demonstrates test cases for option #1. I'll see 
> if I can add comparable sets of tests for the other two options. [1]
>
> https://gist.github.com/Benvie/5375078
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
I don't have much to add to this discussion, but I would like to point 
out that option 1 would make it much easier to implement symbols in 
SpiderMonkey, so as an implementer I have a vested interested in option 
1 winning out ;-)

In case anybody is interested, I've summarized why implementing symbols 
as primitive types in SpiderMonkey is hard here:
https://bugzilla.mozilla.org/show_bug.cgi?id=645416#c14
github at esdiscuss.org (2013-07-12T02:26:55.549Z)
I don't have much to add to this discussion, but I would like to point out that option 1 would make it much easier to implement symbols in SpiderMonkey, so as an implementer I have a vested interested in option 1 winning out ;-)

In case anybody is interested, I've summarized why implementing symbols as primitive types in SpiderMonkey is hard [here](https://bugzilla.mozilla.org/show_bug.cgi?id=645416#c14)