No, also symbol keys don't pollute for-in, Object.keys or Object.getOwnPropertyNames so they are effectively non-global.

As long as you don't use Symbol.for() that is - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

(I do think symbols are useful though, replied for correctness.)

Symbols created with `Symbol.for` don't pollute any of those things, either.

  let x = Symbol.for("omghax");
  let foo = Object.create(null)
  foo[x] = 'bar';
  Object.keys(foo).length // returns 0

there was already a solution for that: .style in dom elements. it is a place where you dump style properties ad-nausea.

Why not simply add a single new property to Object? It would do the very same thing, would not change the language. it would be readily available to all browsers if you just added that single new key in your logic as you already do with .style and others, and everyone would move on with their lives.

I have to agree this is a duct tape by people thinking they know language design. Now i will have to wait until all browsers have this before i can use. and then i will still have to worry about older browsers (oh android, the IE6 of moment). Not to mention the time browser developers would waste actually improving things will be wasted on that syntax sugar.

Symbols are used all the time in Ruby (and a bunch of other languages), not as duct tape but as a very core feature of the language. Why should it be different in JavaScript?

The most simple way to use them is to replace definitions like this one

    var north = 1;
    var south = 2;
    var east = 3;
    var west = 4;
    var direction1 = north;
    var direction2 = south;
    direction1 === direction2 ? "ops" : "ok";

The programmer is doing the work of the interprer/compiler here and make sure to pick unique values for all the constants that are going to be compared together. With symbols that becomes

    var north = new Symbol();
    var south = new Symbol();
    var east = new Symbol();
    var west = new Symbol();
    var direction1 = north;
    var direction2 = south;
    direction1 === direction2 ? "ops" : "ok";

which is an improvement even if it is (in a traditional JavaScript way) so much more verbose than Ruby's

    direction1 = :north
    direction2 = :south
    direction1 === direction2 ? "ops" : "ok"

I just wish they'll add some syntactical sugar to do without that "new Symbol()" thing and create symbols as needed like Ruby does.

Unfortunately, from https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

    Symbols and JSON.stringify()

    Symbol-keyed properties will be completely ignored when using JSON.stringify():

    JSON.stringify({[Symbol("foo")]: "foo"});                 
    // '{}'

We're going to manually serialize them when they leave the RAM.

The base use case for JS symbols is not the same as Ruby symbols: regular strings will work just fine for that.

Symbols in ruby might have the same name but are fundamentally different. E.g. in ruby `:foo` and `:foo` are the same thing. In JavaScript, they are quite explicitly not the same thing. They share little in common (in terms of how they work and what they are designed to do) but the name.

N, E, S, W? I think you want an enum for that.

It was an example of replacing constants with symbols when the value of the constant really doesn't matter. Purposely not fancy stuff. I understand the advantages of enums (among the others, their values are constrained) but does JS have enums?

> does JS have enums?

No, but TypeScript and Dart do.

Enums don't really work without types.

But using Symbols for fake enums is probably a good idea.

    class Enum {
      constructor(...props) {
        props.forEach(p => this[p] = Symbol(p));
      }
    }
    const dir = Object.freeze(new Enum(...'NESW'));
    console.log(dir.E === dir.E); // true
    console.log(dir.E === dir.N); // false

Slightly awkward, but this might be about as good as it gets.

I should have used Object.freeze(this) in the c'tor.