Symbols, Protocols, Frames, and Versioning

David Bruant bruant.d at
Sat Oct 6 04:47:25 PDT 2012

I think there is an idea which hasn't been mentionned yet which would be
to let programmers "merge" or "assimilate" cross-frame symbols.
Basically, when receiving a symbol from some frame, it'd be possible to
say "I assimilate this symbol I received from another frame to my own
I haven't thought about all the cases and details, but the idea behind
it is to let users match symbols the way they wish preserving

I think it would provide a way to solve both cross-frame and maybe
dependency-tree issues.


Le 03/10/2012 19:40, Kevin Smith a écrit :
> One of the main use cases for symbols is for defining object
> "protocols" that don't suffer from property name conflicts.  The
> recently discussed `iterator` and `toStringTag` method names fall into
> this category.  The idea is that we can implement the protocol by
> defining methods using symbols, and thus avoid namespacing considerations.
> Designing and maintaining a global namespace is, well, no fun.
> But consider the multiple-global case in which we have scripts running
> in more than one frame.  It seems like protocols should be
> transferrable across frames.  For built-in protocols like `iterator`,
> this has to work:
>     function f(iterable) {
>       for (x of iterable) {
>         // This must work regardless of which frame `iterable` comes from
>       }
>     }
> But what about user-defined protocols?  Let's say we have a
> "Persistable" protocol:
>     export var persistName = new Symbol; // unique, not "private"
> And a function which makes use of this protocol:
>     import persistName from "Persistable.js";
>     function usePersistable(obj) {
>       if (obj[persistName])
>         obj[persistName]();
>     }
> It seems like `usePersistable` should be able to work as expected even
> if `obj` comes from a different frame (in which "Persistable.js" was
> separately loaded).
> Another expression of the same problem occurs with versioning.
> Suppose that in a fairly complex module dependency graph,
> "Persistable-0.1.js" and "Persistable-0.2.js" are simultaneously
> loaded. ("Persistable" is on github and therefore in perpetual
> version-zero purgatory.)  It seems reasonable to expect that objects
> implementing the protocol defined by "Persistable-0.2.js" should be
> able to work with functions consuming the "Persistable-0.1.js"
> protocol.  But that is not possible with unique symbols.
> In summary, I don't think that we can really avoid global namespacing
> issues using system-generated unique symbols as we currently conceive
> of them.  Built-in protocols like `iterator` are a special "cheating"
> case, but we need to have an equally consistent story for user-defined
> protocols.
> Kevin
> This body part will be downloaded on demand.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list