top | item 9786552

Metaprogramming in ES6: Symbols and why they're awesome

104 points| jessaustin | 10 years ago |blog.keithcirkel.co.uk

43 comments

order
[+] current_call|10 years ago|reply
If programming can be described as "making programs", metaprogramming could be described as "making programs making programs" - or something. You probably use metaprogramming every day perhaps without even noticing it.

Compared to other languages like Ruby or Python, JavaScript's metaprogramming features are not yet as advanced - especially when it comes to nifty tools like Operator Overloading, but ES6 is starting to level the playing field.

What isn't metaprogramming now?

This feels very relevant. http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...

[+] AdieuToLogic|10 years ago|reply
If I could up-vote recursively until the Inter-tubes segfaulted, I would on that link you provided.

A couple quotable lines from the article I have to throw out there are:

> One day, Netscape woke up from a truly epic bender to discover it had jammed a scripting language onto the web and millions of people were using it. Literally none of them liked it. Not one.

> Lots of programmers believe JavaScript is “basically” Scheme because it gives them something they want to believe: that the language they choose to use has some cachet and they don’t have to feel bad about it anymore.

[+] thomasfoster96|10 years ago|reply
I think that link needs a bit of updating - JS has lexical scoping and tail call elimination now.
[+] lispm|10 years ago|reply
Symbols in ES6 are much like symbols in Lisp. Basically much where Lisp software uses symbols applies to ES6.

The main difference: Lisp has simple printed representations for interned, uninterned and keyword symbols.

    CL-USER 23 > (let ((color-interned-symbols   '  (yellow   green   red))
                       (color-uninterned-symbols '(#:yellow #:green #:red))
                       (color-keyword-symbols    '( :yellow  :green  :red)))
                   (list color-interned-symbols
                         color-uninterned-symbols
                         color-keyword-symbols))
    ((YELLOW GREEN RED) (#:YELLOW #:GREEN #:RED) (:YELLOW :GREEN :RED))
Lisp also has packages for namespaces of symbols.

Here you can learn more about computing with symbols, in Lisp:

https://www.cs.cmu.edu/~dst/LispBook/

[+] kowdermeister|10 years ago|reply
Please, don't ever use foo/bar examples. No better way to bore and confuse the reader. It's the worst way to educate people about the possibilities of the thing you want to teach about.
[+] carussell|10 years ago|reply
In the past, I hardly ever used foo and bar in my examples, for that reason. Over the last two years or so, I've strived to start using them.

There's history of using foo/bar/baz in examples. So it's a very quick way to signal to the reader, "What this is isn't the important part. The meat of the discussion isn't in this; he crux of it lies elsewhere," and that's a pretty important thing.

There's a cost in using "real" examples. There's a cost to you the author in coming up with them, and then there's the cost to the reader who has to unpack the domain-specific concepts in the example you're synthesizing and disentangle it from what you're actually trying to demonstrate.

Do use foo and bar whenever possible.

[+] kwhitefoot|10 years ago|reply
What alternative do you have in mind?
[+] zmmmmm|10 years ago|reply
The global symbol registry sounds intriguing but dangerous. Does it now provide a mechanism for client side cross domain communication? The browser spends most of its time isolating different domains, but in this instance the feature seems to be explicitly added to allow for some kind of cross domain interaction. In turn however that would seem to bring with it all the security problems of allowing it - phishing sites can frame your web site and then farm all the information out of the global symbols. Which means any use of them would have to be very careful.

Does anybody have any insight on whether my interpretation here is correct?

[+] girvo|10 years ago|reply
Iirc, there are still ways to communicate between frames (postMessage rings a bell?) -- the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself :)
[+] Manishearth|10 years ago|reply
Symbols are opaque aside from their tag. The global registry just means that you can have cross domain opaque identifiers which are equal; which is useful for communication.
[+] braythwayt|10 years ago|reply

  > the only way to get the Symbols within an Object
  > is Object.getOwnPropertySymbols
Also, Reflect.getOwnKeys.
[+] seanalltogether|10 years ago|reply
This is a bit confusing to me, if the key doesn't matter and no two symbols are equal, why would you ever use

var foo = Symbol('foo')

over

var foo = Symbol()

[+] kannanvijayan|10 years ago|reply
Mostly as a debugging aid. Stringifying the symbol will let you get at the internal string, which can be useful for tooling, introspection, etc.
[+] ww520|10 years ago|reply
If symbols of an object cannot be iterated over, does that mean they cannot be serialized into JSON? Also a symbol doesn't have a unique string representation, Symbol('foo') != another Symbol('foo'), does that mean they cannot be deserialized from JSON?
[+] loganfsmyth|10 years ago|reply
JSON is a very specific subset of JavaScript, and there is no literal syntax for Symbols, so there is no defined way to represent a symbol at the moment. Unless you wanted to encode them as a function call or something, which sounds terrible.
[+] reverius42|10 years ago|reply
I don't think they can be represented in JSON. There are already other JS primitive types that can't be represented in JSON (Date) so at least it isn't introducing any inconsistency... JSON is only a subset of JS objects.
[+] thinkingkong|10 years ago|reply
Not by default. But because there are possible overlaps in keys represented as strings it probably wouldnt be too helpful. Otherwise you could write your own .toJSON method to iterate over the symbol set if you really wanted to.
[+] baddox|10 years ago|reply
I don't know how the default JSON serializers/deserializers work, but I suspect that wouldn't work with symbols. You could probably get something working with Symbol.for().
[+] thomasfoster96|10 years ago|reply
I hadn't really been able see how useful well-known Symbols would be until I read this. My only thoughts now are that overriding binary operators in ES7 would be an amazing feature addition.
[+] jarek-foksa|10 years ago|reply
Why window.Symbol looks like a constructor, but works like a factory? Wouldn't it make more sense to have either a regular constructor (let symbol = new Symbol()) or a regular factory (let symbol = createSymbol())? If it looks like a duck, it should also walk like one.

When subclassing, what is the advantage of [Symbol.toStringTag] getter over the toString() method override? Is it just another way to do the same thing?

[+] gchpaco|10 years ago|reply
The Symbol workaround cannot ever clash with uses of `with`. Granted almost everybody considers `with` to be a bad idea nowadays, but that's part of the rationale.
[+] zipolupu|10 years ago|reply
The second example of Symbol.isConcatSpreadable should assert "z" equality, not "y"
[+] nawitus|10 years ago|reply
I think "getOwnSymbols" should be "getOwnPropertySymbols".
[+] carussell|10 years ago|reply
This can be the copy editing subthread.

See zipolupu's comment https://news.ycombinator.com/item?id=9790181

The article also says:

> When you see code like rho == lho it could be converted into rho[Symbol.isAbstractEqual](lho), allowing classes to override what == means to them.

While there's not any technical error here (the examples follow proper alpha-conversion), the "l" and "r" in lho and rho stand for "left" and "right", respectively, so they should be switched.

In the Symbol.match example, "return [find];" should be... "return [index];"?