7

I'm toying around with ES6, looking at symbols. Unlike ruby for example where you'd write :symbol, ES6 symbols seem to be allowed any "standard" variable name. To be honest I am finding this rather confusing:

var privateProperty = Symbol();
var obj = {};
obj[privateProperty] = 'some value goes here';

as it tends to make me think that privateProperty is probably a plain string like the years before. Using :privateProperty is not valid.

So just like using $bar for a jQuery object or bar$ for a RxJS/Bacon stream, I was wondering if there is already an established convention for naming symbols in ES6?

m90
  • 11,434
  • 13
  • 62
  • 112
  • 1
    A symbol is just a value. The variable you assign it to is not its name. The variable is just a container for the value, just like for any other value (number, string, object, ...). – Felix Kling Jul 11 '15 at 12:58
  • I am aware of that, my example is just misleading, editing. – m90 Jul 11 '15 at 13:00
  • Changing the variable name doesn't really make any difference. – Felix Kling Jul 11 '15 at 17:16

1 Answers1

6

obj[privateProperty] = …; tends to make me think that privateProperty is probably a plain string like the years before.

Well, that's the old thinking that we will need to forget. privateProperty is a key, which can be either a string (property name) or symbol. Similarly, we already have learned to distinguish (integer) indices from "normal" properties.

ES6 seems to allow any "standard" variable name

Just as does Ruby. The difference is that ES6 doesn't introduce a literal notation for symbols (which resolve to the same thing), but allows them to be created only by using Symbol (locally) or Symbol.for (globally).

There is no standard convention for naming variables that hold symbol values.
Of course, you can always use hungarian notation if you tend to want such type annotations. If I had to coin a standard, I'd propose to use a more subtle leading underscore (var _myPrivate). Underscores in property names had always implied something special, and it would look similar for computed property keys (obj[_myPrivate]) then.

Is there a convention for naming symbols in ES6?

While there is no convention for naming symbol-holding variables (yet), there certainly is a convention for naming symbols themselves:

  • local symbols should have a very descriptive descriptor string (given as an argument to Symbol). Of course, they're still unique anyway, so you basically can use whatever name you want.
  • global symbols need to avoid collisions. The convention is to namespace them appropriately, and connect those namespace names with dots - like a Java package name. If the symbol is available as a global variable, its descriptor should have the same name (similar to the builtin, native symbols, which are like @@iterator = Symbol.for("Symbol.iterator");). If the symbol is exported by a module or library, its descriptor should be prefixed with the module/library name (to avoid collisions).

And it would probably be a best practise to use the same name for the variable (like the native symbols already do, Symbol.iterator.toString() == "Symbol(Symbol.iterator)").

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • What is about variables that hold references to Symbols? Sometimes I store them in objects but sometimes in distinct variables as well. There can be name collisions in my own code, when a function would have to have the same name. I tend to write those vars in upper case: `const MAP = Symbol("map")` but am not sure. Oh, and Symbols are immutable. –  Jan 16 '16 at 11:02
  • @IvenMarquardt As I said, there is no convention for those either. Using uppercase names in your case is probably more because it's a constant, less because it holds a symbol. – Bergi Jan 16 '16 at 11:09