Metaprogramming in ES6: Symbols and why they're awesome(blog.keithcirkel.co.uk)
blog.keithcirkel.co.uk
Metaprogramming in ES6: Symbols and why they're awesome
http://blog.keithcirkel.co.uk/metaprogramming-in-es6-symbols/
45 comments
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.
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.
Lots of languages claim they are Scheme or Lisp dialects (JavaScript, Python, Ruby, Lua and others) in order to boost their popularity even though they have none of Lisp's unique features but just the general features you would expect to find in any dynamically typed languages.
Python claims it's a Scheme/Lisp dialect? Where?
I think that link needs a bit of updating - JS has lexical scoping and tail call elimination now.
> JS has [...] tail call elimination now.
In a very narrow hay of "has", as in "ES2015 the spec has it, but no JS runtime implements it yet": http://kangax.github.io/compat-table/es6/#proper_tail_calls_...
I'm not trying to be a contrarian. It's just that i see lots of JS developers excited about superfluous things like class syntax or symbols, whereas real game changing additions like proper tail calls seem to pass by unnoticed, and unimplemented by JS runtimes :(
In a very narrow hay of "has", as in "ES2015 the spec has it, but no JS runtime implements it yet": http://kangax.github.io/compat-table/es6/#proper_tail_calls_...
I'm not trying to be a contrarian. It's just that i see lots of JS developers excited about superfluous things like class syntax or symbols, whereas real game changing additions like proper tail calls seem to pass by unnoticed, and unimplemented by JS runtimes :(
I tried to create an infinite loop in Firefox and got a "InternalError: too much recursion". Then when I tried it in Chrome I got "Uncaught RangeError: Maximum call stack size exceeded".
function x() { return x(); }
function x() { return x(); }
I think you misunderstood "now". It's "now" as in ES6/ES2015, not ES5 which the browsers are running by default.
That's still expected?
It's a recursive tail call. It should run forever, like the following Scheme code.
(define (foo) (foo))
(foo)
(define (foo) (foo))
(foo)
Ah, right, yes I get what you mean.
The main problem is still that Chrome and Firefox don't support tail call elimination. Babel (6to5) and Traceur do.
The main problem is still that Chrome and Firefox don't support tail call elimination. Babel (6to5) and Traceur do.
They don't. They support an optimization for self recursive calls but not general tail call elimination.
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.
Here you can learn more about computing with symbols, in Lisp:
https://www.cs.cmu.edu/~dst/LispBook/
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))
Here you can learn more about computing with symbols, in Lisp:
https://www.cs.cmu.edu/~dst/LispBook/
url doesn't work (Forbidden, You do not have permission to access the requested address (URL)).
In any case, I think the book parent is referring to: http://www.amazon.com/Common-LISP-Introduction-Computation-E...
In any case, I think the book parent is referring to: http://www.amazon.com/Common-LISP-Introduction-Computation-E...
Maybe on your side. Not here. Works fine. The book is for download from there.
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.
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.
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.
What alternative do you have in mind?
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?
Does anybody have any insight on whether my interpretation here is correct?
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 :)
I'm curious if Symbols are valid for localStorage keys.. it could be used as communication channels between frames that way, I seem to remember a post for something like that, and Symbols may be a bit safer.. though not sure if Symbol.for('__my_channel__') is safer than '__my_channel__' in this case (same domain). Though the cross-domain bit is slightly interesting, I'm not really sure what the risk would be in practice.
> the global symbols don't really hold any information though, and are mostly just markers that are used in the code itself
Global flags always represent information, be it to the people who code them up or attackers who leverage their existence.
Global flags always represent information, be it to the people who code them up or attackers who leverage their existence.
I can't see any reliable extra information available, based on the description in the article.
The only thing I can think of offhand: time the execution of Symbol.for. Mostly, this won't be terribly illuminating, because the bulk of the work (hashing input + looking in table) will be the same in both cases, and won't take long. But, assuming the registry is a hash table, what you could do in one script is pollute the registry with enough strings to trigger several hash table rebuilds (which you can detect by outsize results from Symbol.for - you add enough strings to provide a good representative set of timings).
Then another script could detect this by doing the same operation and seeing if no call to Symbol.for took much longer than any other. This gets you 1 bit of information... is that useful?
(Also, I wonder what they do about symbol table exhaustion.)
As for the results, they don't themselves hold any extra information, I don't think. Regarding Symbol.for: if the table contained the requested symbol already, it will return that symbol. If it didn't, a new symbol will be added, and returned. These are the only two options, and the caller has no way of knowing which was taken.
And regarding Symbol.keyFor: if the input was previously returned by Symbol.for, returns true. And if not, returns false. Neither tells you anything because the caller can only have acquired the symbol by doing one of these two operations itself, meaning it isn't getting any information that it didn't in theory have already.
The only thing I can think of offhand: time the execution of Symbol.for. Mostly, this won't be terribly illuminating, because the bulk of the work (hashing input + looking in table) will be the same in both cases, and won't take long. But, assuming the registry is a hash table, what you could do in one script is pollute the registry with enough strings to trigger several hash table rebuilds (which you can detect by outsize results from Symbol.for - you add enough strings to provide a good representative set of timings).
Then another script could detect this by doing the same operation and seeing if no call to Symbol.for took much longer than any other. This gets you 1 bit of information... is that useful?
(Also, I wonder what they do about symbol table exhaustion.)
As for the results, they don't themselves hold any extra information, I don't think. Regarding Symbol.for: if the table contained the requested symbol already, it will return that symbol. If it didn't, a new symbol will be added, and returned. These are the only two options, and the caller has no way of knowing which was taken.
And regarding Symbol.keyFor: if the input was previously returned by Symbol.for, returns true. And if not, returns false. Neither tells you anything because the caller can only have acquired the symbol by doing one of these two operations itself, meaning it isn't getting any information that it didn't in theory have already.
That's the thing. The "existence" of a global symbol isn't observable.
Think of `Symbol.for("foo")` as if it were the string "foo". The string "foo" is also global, when passed across iframe boundaries it still retains its meaning. One can use this string on either side. Using it doesn't observably instantiate some global flag, though internally there may be interning and whatnot. Similarly, using Symbol.for("foo") doesn't instantiate any flag, observably.
Think of `Symbol.for("foo")` as if it were the string "foo". The string "foo" is also global, when passed across iframe boundaries it still retains its meaning. One can use this string on either side. Using it doesn't observably instantiate some global flag, though internally there may be interning and whatnot. Similarly, using Symbol.for("foo") doesn't instantiate any flag, observably.
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.
Funny... I think I've heard this line of reasoning before:
https://technet.microsoft.com/en-us/library/cc781906(v=ws.10...
https://technet.microsoft.com/en-us/library/cc781906(v=ws.10...
Global symbols can be thought of as "keys which always existed" and they don't have values.
You can't determine if a global symbol is being used by another frame. They just ... exist.
You can't determine if a global symbol is being used by another frame. They just ... exist.
> the only way to get the Symbols within an Object
> is Object.getOwnPropertySymbols
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()
var foo = Symbol('foo')
over
var foo = Symbol()
Mostly as a debugging aid. Stringifying the symbol will let you get at the internal string, which can be useful for tooling, introspection, etc.
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?
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.
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.
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.
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().
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.
mirror: http://webcache.googleusercontent.com/search?q=cache:9lmo3WI...
Edit: now it's back up online.
Any examples of using symbols for variants or flyweights ?
Edit: now it's back up online.
Any examples of using symbols for variants or flyweights ?
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?
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?
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.
The second example of Symbol.isConcatSpreadable should assert "z" equality, not "y"
I think "getOwnSymbols" should be "getOwnPropertySymbols".
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];"?
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];"?
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...