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