What is the point of the 'Symbol' type in ECMA-262-v6?

Question

What is the point of the 'Symbol' type in ECMA-262-v6? Fast path implementation for object keys? What does it do under the hood - hash it with the guarantee that the underlying data is immutable?

Answer 1

Symbols are private keys that replace magic names. They prevent using a simple string to reference the field, so only consumers with the symbol can gain access.

Some symbols are used to indicate particular behaviors to the runtime (like Symbol.iterator, which acts much like a pre-shared secret), while others can be allocated by the library and used to effectively hide fields.

In general, symbols are intended as a replacement for magical names. Rather than having a properties simply called 'foo', you can allocate a symbol const foo = Symbol() and pass that selectively. This allows the runtime to allocate Symbol.iterator when it starts up and guarantees that anyone trying to implement an iterable does so in a consistent fashion.

The runtime could use symbols to optimize access to certain fields, if it felt the need to, but doesn't have to.

You can use symbols to direct consumers to a particular method, depending on their usage. For example, if you had a library that could return a synchronous iterable or a generator, depending on the client's async support, you could:

const syncIterable = Symbol();
const asyncIterable = Symbol();

class Foo {
  static getIterable(async = false) {
    return async ? asyncIterable : syncIterable;
  }

  [syncIterable]() {
    return new SyncFoo();
  }

  [asyncIterable]() {
    return new AsyncFoo();
  }
}

let foo = new Foo();
for (let x of foo[Foo.getIterable(true)]()) {
  // could be a iterator, could be a generator
}

That's a rather contrived example, but shows how a library can use symbols to selectively provide access to users.

Answer 2

They pretty much help us having naming collisions. Anytime that you want to create a property in a unique way, that's when you should reach for a symbol.

Take a look at my example

const bert = Symbol('Bert');

'Bert'

Note: this is not a value this is what they called a descriptor, because the symbol itself is just a unique identifier. So if you were to visualize what a symbol would be maybe you can visualize is as something like this "sdfasdfa2342134987fgsdfgsdf9808fsfgsd" absolute unique symbol so that you can make sure that it will never overrides any other piece of code in there.

What's cool about this is if I create a second symbol, like

const person = Symbol('Bert')

You can see I used 'Bert' again. Are those going to be the same because I described them as the same thing?

const bert = Symbol('Bert');
const person = Symbol('Bert');


console.log(bert);
console.log(person);
console.log(bert === person);
console.log(bert == person);

This can be useful if you were creating an object of your class.

  const classRoom = {
    'Mia' : { grade: 50, gender: 'female' },
    'Gilbert': { grade: 80, gender: 'male' },
    'Gilbert' { grade: 80, gender: 'male' },
  };

But then you have another named Gilbert, so you got a naming collision there. So imagine if you're working on million and millions of data. So rather than using the persons name or using some sort of unique identifier we can use a symbol to name them.

  const classRoom = {
    [Symbol('Mia')] : { grade: 50, gender: 'female' },
    [Symbol('Gilbert')]: { grade: 80, gender: 'male' },
    [Symbol('Gilbert')]: { grade: 80, gender: 'male' },
  };

Another thing about symbols is that they are not enumerable, which means we cannot loop over them if I were to do

  for (const person in classRoom) {
    console.log(person);
  }

I get nothing.

If you do want to get access to all your symbols because theyres some information that you want to get you can use the object method.

  const syms = Object.getOwnPropertySymbols(classRoom);
  const data = syms.map(sym => classRoom[sym]);
  console.log(data);