Symbols, Protocols, Frames, and Versioning

Brendan Eich brendan at
Wed Oct 3 17:51:55 PDT 2012

Dean Landolt wrote:
> On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> 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 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?


More information about the es-discuss mailing list