from Hacker News

ES6 in Depth – Symbols

by jansc on 6/12/15, 9:11 AM with 69 comments

• by nni on 6/12/15, 2:25 PM

  It is my understanding that symbols were going to be a way to have private methods. This aspect of them - the reason they were going to be introduced in the first place - was dropped, and so you are left with its current limited form with a much narrower use-case.

  From A Rossberg (he's also the guy behind SoundScript) in a March 2014 stackoverflow post (http://stackoverflow.com/questions/21724326/why-bring-symbol...):

  "Enabling private properties ... was indeed the original motivation for introducing symbols into JavaScript. Unfortunately, however, they ended up being severely downgraded, and not private after all.

  They are now known as unique symbols, and their only use is to avoid name clashes between properties....Whether that is strong enough a motivation to add symbols to the language is debatable."

  and from R. Waldron as part of this response (https://esdiscuss.org/topic/proposal-about-private-symbol) to a proposal about a private symbol (Dec 2014)

  "Ultimately it was decided that Symbol is just a symbol and that "private" things will be dealt with orthogonally (and at a later date)."

  YMMV

• by lispm on 6/12/15, 1:43 PM

  > Calling Symbol() creates a new symbol, a value that’s not equal to any other value.

  Lisp:

      CL-USER 1 > (eq (make-symbol "Foo") (make-symbol "Foo"))
      NIL
  

  > Symbols aren’t exactly like anything else

      CL-USER 2 > (type-of (make-symbol "Foo"))
      SYMBOL
  

  > Trying to concatenate a symbol with strings will result in a TypeError.

      CL-USER 3 > (concatenate 'string "abc" 'foo "def")
  
      Error: In a call to LENGTH: FOO (of type SYMBOL) is not of type SEQUENCE.
  
  

  > There are three ways to obtain a symbol.

  > Call Symbol()

      (make-symbol "FOO")
  

  > Call Symbol.for(string)

      (find-symbol "FOO")
  

  Other than that symbols in Common Lisp have a package, a value, a function and a property list. Symbols can be interned in a package or not. So-called Keyword symbols are in the package KEYWORD and have itself as the value. :I-AM-A-KEYWORD evaluates to :I-AM-A-KEYWORD.

• by unwind on 6/12/15, 10:42 AM

  As a very green JS programmer, I found this post informative and fun.

  I think this sentence has an editing mistake in it:

      It’s simply a property whose name is not a symbol rather than a string. 
  

  I think that the "not" shouldn't be there, the double negation makes the sentence fail to parse for me at least (ObCaveat: not a native speaker).

• by yoshuaw on 6/12/15, 10:48 AM

  I wrote a lil' article about using Symbols a month ago - https://medium.com/code-ops/party-tricks-with-es6-symbols-ee...

  Probably the most interesting use I've found for Symbols so far is to detect if an object / function was created by a specific factory - https://gist.github.com/yoshuawuyts/2bf8d5394e6f995791a0

• by BinaryIdiot on 6/12/15, 5:01 PM

  Symbols are odd. Maybe it's just me but they feel like they work "funny" in JavaScript.

  As the article says you can't implicitly convert a symbol's description to string. Symbol is now the only native object in JavaScript that has this behavior.

  var str = "something" + "str"; // Works

  var num = "something" + 5; // Works

  var func = "something" + function () { }; // Works

  var obj = "something" + { some: "test" }; // Works

  var bool = "something" + true; // Works

  var dt = "something" + Date.now(); // Works

  var und = "something" + undefined; // Works

  var nul = "something" + null; // Works

  var nan = "something" + NaN; // Works

  var sym = "something" + Symbol("test"); // Throws TypeError

  Another thing, which is more of a style thing in my opinion, is you can actually define a property with a Symbol which just seems awkward to me. I mean sure you can use it as a property by design so why wouldn't you be able to use defineProperty? I always felt those should be public types of properties where you can add additional logic where necessary.

  var obj = { };

  Object.defineProperty(obj, Symbol("MyProp"), {

      get: function () { return 15; } 
  

  });

  I feel like almost the same thing with Symbol could be accomplished with a simple UUID generator. It's a neat little thing it just feels awkward to me with how JavaScript works.

• by skrebbel on 6/12/15, 10:09 AM

  I don't understand why the author compares ES6 symbols to Ruby symbols; they're nothing alike. It's kind of the opposite: Ruby symbols are guaranteed to be the same object if they have the same name, ES6 symbols are guaranteed to be a different object, even if they have the same name (description)

• by meric on 6/12/15, 11:42 AM

  Looks like Symbols is a type being introduced because objects, when used as a key in another object, gets turned into a string, unlike Lua tables can be used as keys of other tables, and are guaranteed to not be equal to any other value. Lua tables are built-in symbols. Javascript's objects are not.

• by IshKebab on 6/12/15, 12:17 PM

  I wish javascript had some kind of flag so you could get it to act sanely. All the comparison operators would work like they do in sane languages; type conversion wouldn't be quite so automatic and insane, etc.

• by nabla9 on 6/12/15, 10:40 AM

  This is very limited symbol type. They might have named them keywords instead. It's just interned string with a new type.

  (It's like Common Lisp symbols limited inside the keyword package)

• by welfare on 6/12/15, 10:51 AM

  I'm not entirely convinced with the function-call syntax for declaring a Symbol.

  Why not using something more of the lines with Ruby's :symbol syntax?

• by asdf99 on 6/12/15, 9:59 AM

  yet another duct tape kind of feature, from people already too corrupted by js, that will be further abused and cause yet more duct tape features in ES7.

  this is nothing but a more convoluted way of the pattern that sets a unique object as a unique value for comparison. well, it adds a label for easy debug. hooray.

• by agd on 6/12/15, 12:47 PM

  Call Symbol.for(string). This accesses a set of existing symbols called the symbol registry. Unlike the unique symbols defined by Symbol(), symbols in the symbol registry are shared. If you call Symbol.for("cat") thirty times, it will return the same symbol each time. The registry is useful when multiple web pages, or multiple modules within the same web page, need to share a symbol.

  Have they added inbuilt support for globals here? People could easily add their own global symbols, why does this need to be built in?

• by jordanwallwork on 6/12/15, 12:23 PM

  I'm not from a Ruby/Lisp background, so I don't know how symbols are typically used, but the explanation of why symbols are required is to prevent collisions if two libraries chose to use the same property name; so given that, what is the point of the Symbol registry? I don't understand what the value of a symbol that is referenced by a string is, over simply using the string?

• by espadrine on 6/12/15, 10:20 AM

  If you think that this language feature has no equivalent in your favorite language, it is similar to Ruby's :symbol, where it is mostly used as keys to their hash tables (they're implemented with hashes internally).

  Common Lisp has something even closer for its macro system. When you write code that writes code, you often need to create new variable names that won't collide or shadow anything. `(gensym)` does that: http://www.lispworks.com/documentation/lw50/CLHS/Body/f_gens....

  Here's a list of languages with support for symbols. You will see even Objective-C has it: https://en.wikipedia.org/wiki/Symbol_%28programming%29#Suppo....

  I'd be curious to learn how it is implemented in JS engines.

• by xienze on 6/12/15, 11:56 AM

  > Sometimes it would be awfully convenient to stash some extra data on a JavaScript object that really belongs to someone else.

  Convenient yes, a good idea, no.

  > Other code using for-in or Object.keys() may stumble over the property you created.

  > The standard committee may decide to add an .isMoving() method to all elements. Then you’re really hosed!

  So I dunno, maybe don't stash properties into an object that doesn't belong to you? It's this sort of thing that makes me hate the culture around JavaScript. Hacks upon hacks upon hacks just to save a little effort.