On Oct 3, 2012, at 2:09 PM, Brendan Eich wrote: > Domenic Denicola wrote: >> Would it suffice to allow cross-frame sharing of symbols via postMessage and >> its structured clone algorithm? They're immutable, right? > > They are immutable but you'd still have to pass your @iterator to another > same-origin frame, and then have to use it carefully when iterating objects > from the first frame. This is unusable. > > Making @iterator a singleton (to the limits of observability: same-origin, > CORS, out-of-process-via-DOM window.open in IE9+ notwithstanding!) can be > done. That wins, no need to pass and use the other frame's @iterator symbol. > > But how to let users create such singletons? >
It isn't an issue about creating them, it's an issue about communicating them. This issue came up briefly yesterday on the "prototypes as valid instances" thread: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025453.html where it was brought up in the context of cross-frame branding of the internal state of self-hosted built-ins. Regarding @@iterator, @@toStringTag and any other specification defined unique symbols, my intent is that there will be spec language that says that there is a single value for each of them that is used across all Realms/contexts/frames (whatever terminology ultimately sticks). Note that this is not necessarily the case for all private symbols that might be used by the spec. or an implementation to reference private state of built-ins. Such symbols might need to be uniquely instantiated for each Realm/context/frame, it depends upon the actual design of the abstraction that is being created. If a symbol is going to be used as an access key, then there must be a means of distributing it to its intended users. For built-in symbols like @@iterator this is probably going to be via an export from from a standard module. Presumably a similar technique could be used for user defined symbols that need to be shared across frame but the needs to be a way to communicate the actual shared symbol values to the module instance associated with each realm. In the above referenced message I suggest that this may be a job for the module loader API, but I haven't tried to work out the details. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
