Discuss
  • Question about Symbols and GlobalSymbolRegistry

Question about Symbols and GlobalSymbolRegistry

# Cyrus Najmabadi (10 years ago)

I am reading the Symbol section of the ES6 spec (19.4), and my understanding is that calling the Symbol constructor does not add an entry to the GlobalSymbolRegistry. Is that correct?

For example:

var s1 = Symbol("foo");
var s2 = Symbol.for("foo");

In this example, s1 and s2 would be two distinct symbols. And in the following example:

var s1 = Symbol("foo");
var s2 = Symbol.keyFor(s1);

In this example, s2 would be undefined.

Am I understanding correctly?

# Axel Rauschmayer (10 years ago)

Correct. The registry is only accessed via Symbol.for(key) and Symbol.keyFor(sym). The parameter of Symbol() is a description, not a key.

# Kevin Smith (10 years ago)

Am I understanding correctly?

Yes. The argument to the Symbol constructor is just a descriptive string.

# Cyrus Najmabadi (10 years ago)

A couple more questions.

  1. Are the built-in symbols (like ‘Symbol.iterator’) in the GlobalSymbolRegsitry?

  2. If so, what are their keys? i.e. how would one reach Symbol.iterator using Symbol.for(…)?

# Jordan Harband (10 years ago)

They are not - if they were, then adding a new well-known symbol like Symbol.foo would fail if anyone had code that did Symbol.for('foo'). (I have no idea if that is the reason, but certainly that's a reason not to make them available via the registry)

# Axel Rauschmayer (10 years ago)

It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as "ecmascript.org/symbol/foo, ecmascript.org/symbol/foo".

# Brendan Eich (10 years ago)

Axel Rauschmayer wrote:

It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as "ecmascript.org/symbol/foo".

Symbol.iterator and the other well-known symbols are self-same in all connected realms. See people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-symbols.

So there's no need for this (and URLs suck for such things; plus, you probably mean URIs, but I don't care enough to check!).

# Axel Rauschmayer (10 years ago)

On 28 Jan 2015, at 00:06, Brendan Eich <brendan at mozilla.org> wrote:

So there's no need for this

There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON).

(and URLs suck for such things; plus, you probably mean URIs, but I don't care enough to check!).

Yes, I mean URIs(?)

# Brendan Eich (10 years ago)

Axel Rauschmayer wrote:

There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON).

Symbols that user-code puts into the registry do not serialize this way, so why should the well-known ones?

If you want to write a JSON helper-pair (toJSON or a replacer, with a correponding reviver, I think), then you can indeed serialize and deserialize symbols. But there's no ES6 backstage default-wiring from JSON to Symbol.for/keyFor.