On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg <[email protected]> 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
[email protected]
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
