Symbols, Protocols, Frames, and Versioning
brendan at mozilla.org
Wed Oct 3 17:51:55 PDT 2012
Dean Landolt wrote:
> On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich <brendan at mozilla.org
> <mailto:brendan at mozilla.org>> 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?
> The module system does this for us, doesn't it? I can't really see the
> problem -- anywhere you can share objects with private symbols you can
> always provide the symbols themselves. Module sandboxes will come in
You're clearly right for built-ins. For a built-in module, say "@iter"
(if we factor it that way), all realms importing @iterator from "@iter"
will get the same singleton symbol.
In any user-defined symbol setting, it's up to the usercode to export
the symbol from a module. But I don't believe we have spec'ed how the
default loader works in a multiple-globals (multiple realms, it's
catchy!) situation where the different globals are connected. Does the
system loader memoize per reachable subgraph of global objects?
More information about the es-discuss