Dean Landolt wrote:
On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> 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
handy.
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?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
