Symbols, Protocols, Frames, and Versioning

Domenic Denicola domenic at domenicdenicola.com
Sat Oct 6 04:53:04 PDT 2012


This approach is kind of what I was getting at with my postMessage point:

window.onmessage = function (data) {
    let iterator2 = data.iterator;
};

But it was pointed out this was rather un-usable, leading to the current discussion.

I still would like to see someone respond to jjb's message though: https://mail.mozilla.org/pipermail/es-discuss/2012-October/025531.html

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of David Bruant
Sent: Saturday, October 6, 2012 13:47
To: Kevin Smith
Cc: es-discuss
Subject: Re: Symbols, Protocols, Frames, and Versioning

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 persistableSymble".
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 unforgeability.

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

David

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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121006/960fdf62/attachment.html>


More information about the es-discuss mailing list