Symbols, Protocols, Frames, and Versioning

Sam Tobin-Hochstadt samth at
Fri Oct 5 07:11:15 PDT 2012

On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <rossberg at> wrote:
> Indeed, which is why I'm not sure I understand what this idea is
> trying to achieve. Is it more than just an ad hoc way to introduce a
> second namespace?

I think what's going on as follows:

 - Symbols, even when not used for encapsulated abstractions, are
great for avoiding the possibility of collision in the global string
 - So, we (tc39) decided to use them for to replace the property name
currently called "iterator" in Spidermonkey.
 - Currently, "iterator" works across same-origin frames, but a naive
use of Symbol for this wouldn't work
 - Therefore, we have a few options:
   1 Give up on Symbols for "iterator"
   2 Make the Symbol replacement for "iterator" magically work across
all same-origin frames
   3 Make iteration not work across frames
   4 Break the web and fix cross-frames to work more sensibly
 - Since the latter two of those are not actual options, (2) seemed
like the best choice.
 - But then we, the language, are doing something that programmers
can't do, so we searched for something else
 - This led to `Symbol.for`, which is not actually allowing
programmers to do (2), but resembles it somewhat

I think we should rethink this whole direction. The bizarreness of
cross-frame interaction is real, and we have to deal with it.  That
means abstractions based on libraries that provide values with
identity won't work cross-frame.  I don't think `Symbol.for` makes
solving any problems that we currently have easier.  Symbols are great
when they're based on sharing values in the heap, and otherwise, we're
stuck with strings.  We can make @iterator a magic Symbol, or we can
stick with a string, and I don't have a good sense of what the right
choice is there, but I think that's separable from `Symbol.for`.

Note also that `Symbol.for` has some really weird behavior. For
example, what does this evaluate to?

    Symbol.for("x") instanceof Symbol

That depends if someone has previously evaluated `Symbol.for("x")` in
a different frame.
sam th
samth at

More information about the es-discuss mailing list