ES6 in Depth – Symbols

https://hacks.mozilla.org/2015/06/es6-in-depth-symbols/

by jansc • 11 years ago

123 65 11 years ago

hacks.mozilla.org

asdf99• 11 years ago

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.

weavie• 11 years ago

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

yoshuaw2• 11 years ago

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.)

pmontra2• 11 years ago

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.

masklinn4• 11 years ago

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

ahoge4• 11 years ago

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

jkrems2• 11 years ago

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.

skrebbel• 11 years ago

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)

espadrine2• 11 years ago

  s1 = Symbol.for('cat')
  s2 = Symbol.for('cat')
  s1 === s2  // true

The most common use-case for them is to generate symbols that don't collide, though.

ahoge4• 11 years ago

`Symbol.for` uses a global registry and the whole thing is "stringly typed".

Looks like an anti-pattern to me.

If you want one particular symbol from some library, you could import it.

espadrine2• 11 years ago

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.

inglor• 11 years ago

Like a property basically - except the key is not a string and is known to the engine. This is both simple and uses existing JIT facilities. Symbol property access isn't particularly slower than regular access this way too.

See http://blog.peschla.net/doxygen/v8_chromium_r157275/classv8_... - it's

masklinn4• 11 years ago

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....

None of the symbols in that table match the purpose and use case for `new Symbol`, though gensym does.

nabla9• 11 years ago

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)

unwind• 11 years ago

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).

yoshuaw2• 11 years ago

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

welfare• 11 years ago

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?

_pmf_• 11 years ago

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

You mean Common Lisp's syntax, of course.

Grue3• 11 years ago

":symbol" is only syntax for keywords though. In general the syntax is "package:symbol" or just "symbol" (if it's in current package).

mrighele• 11 years ago

I guess because they do not behave in the same way. In fact new Symbol() is closer to Common Lisp's (gensym) than regular :symbol, since everytime you call it you get something unique.

In particular object[:symbol] would behave quite differently (and would be probably worthless since everytime you would access a new property ).

It would make more sense to have :symbol a shortcut for Symbol.for("symbol") instead, but I don't think it would be that much useful.

masklinn4• 11 years ago

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

Because Ruby's symbols are completely different and designed to collide. A Ruby symbol (like an Erlang atom) is a very cheap immutable string-like structure but :symbol is :symbol.

A Javascript symbol is (as others noted) much closer to a lisp unique symbol (the output of `gensym`), and having it be a function is perfectly fine since you have to keep it around anyway (or you can't access symbol-named properties).

Symbol.for is roughly equivalent to :symbol, but the use case for it is much more limited and there's really no reason for a literal version./

carussell4• 11 years ago

Here's the other thing that neither of the other commenters mentioned:

You can't go around peppering your code with use of this new syntax if you want it to continue working on older runtimes. With `Symbol`, you can at least create a polyfill that approximates what it's shooting for.

declaring a Symbol

Don't think of it as "declaring a symbol" (because it isn't). Think of it as generating a symbol (because it is).

hajile• 11 years ago

ES6 already adds a ton of new constructs that won't run on older browsers. Relying on symbols to be interned also won't work on older machines. A symbol-literal syntax like #symbol and #"spaced symbol" would make them far easier to use and increase their adoption.

Who really wants to write map.add(new Symbol("foo"), 'bar') instead of map.add(#foo, 'bar')?

serve_yay• 11 years ago

Why add syntax if you don't need to?

meric• 11 years ago

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.

thomasfoster96• 11 years ago

Are you talking about Maps in ES6 or Symbols? Using an object as a key is what you can do with Maps.

bcoates2• 11 years ago

Yeah, it seems like kind of an odd choice to introduce a whole new type and extend the kind of values that can index an object, when extending object indexing alone would do everything symbols do anyway.

quarterto• 11 years ago

It's actually not extending object indexing. From the object's point of view, the symbol is just another (albeit opaque) string.

xienze• 11 years ago

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.

sombremesa• 11 years ago

I don't see why they didn't just use an Object/dictionary. Shouldn't be slow to iterate and solves this exact use case.

IshKebab2• 11 years ago

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.

jordanwallwork4• 11 years ago

If you just make sure to always use === then this is exactly what happens. You can use tools like jslint to warn you if you accidentally use ==

mkolosick• 11 years ago

Not quite though. I had a bug with Javascript where I was reading in a number and forgot to parse it to a float. I ended up doing an addition with that value, which later got used as a float again. So I had 1 + "10" turn to 110 when I tried to use it. No == or === anywhere.

IshKebab2• 11 years ago

That just fixes one of javascript's weirdnesses. There are many many others.

jordanwallwork4• 11 years ago

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?

mohaine• 11 years ago

I think the idea is so that while symbols can prevent collisions, they can also make it impossible to set a value. The registry allows you to set the value by name, but by doing this you have to keep in mind that there might be a name collision and allows you to handle the collision. Before there was no way tell that a name collision even happened.

carussell4• 11 years ago

See `Symbol.hasInstance` and `Symbol.iterator`; take them as examples. Mapping an object to its iterator is going to be part of the spec and will be required at the language level (`for...of`). Before, if you looked at all of an objects' properties in SpiderMonkey, you will have noticed an `@@iterator` property. The spec could achieve the same thing as it's trying for with `Symbol.iterator` by just using a string-valued `@@iterator` property, but you still get the collision with anybody who would have used that name for something else or anyone looping over all the properties.

The gist is this: symbols are just a way to have non-strings that you can use for properties. There are also facilities to generate them in such a way that the symbol will never, ever collide with those generated by somebody else, but that's not their only purpose.

jordanwallwork4• 11 years ago

Ah yeah that makes sense, cheers!

PuercoPop• 11 years ago

One advantage, fast comparison by pointer equality. (Similar to interned strings)

agd3• 11 years ago

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?

carussell4• 11 years ago

Could you reword the question? I don't understand what you're asking.

agd3• 11 years ago

I guess I don't understand why the global symbol registry exists. If someone wants a global symbol map, they can create their own. What else does this add over a user implementation, and what are the use cases?

lispm• 11 years ago

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.

drudru11• 11 years ago

That first example with 'eq is a little surprising to me. Previous to your post, I believed that Common Lisp symbols were equivalent to Lisp atoms. That is, I just thought of symbols as a way of interning strings (like Smalltalk, Objc, Ruby, etc.) ES6 Symbols reminded me of gensym. I didn't expect to see ES6 having the same behaviour as Common Lisp!

Thanks for posting.

nni• 11 years ago

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

braythwayt• 11 years ago

You can still use them to make almost-completely-private methods and properties, it's just the syntactic sugar that was dropped:

http://raganwald.com/2015/06/04/classes-are-expressions.html

HN discussion:

https://news.ycombinator.com/item?id=9660658

BinaryIdiot• 11 years ago

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.

jkrems2• 11 years ago

The other funny thing is: ES6 introduced `Map`, `Set`, and the `class` keyword. All of them throw if you try to create a new instance without `new`. It also introduced `Symbol`, which throws if you do use `new`.

ES6 in Depth – Symbols

Related Stories