On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <rossb...@google.com> 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 namespace - 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 sa...@ccs.neu.edu _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss