Symbols, Protocols, Frames, and Versioning

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Oct 6 10:52:52 PDT 2012


On Oct 6, 2012, at 4:47 AM, David Bruant wrote:

> 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

I submit that this isn't a cross-frame symbol sharing issue, it is a cross frame object sharing issue that also touches upon issues of cross frame module instance sharing.

Here is an isomorphic problem that doesn't involve symbols:

Assume you wish each frame to have a global binding named SharedObjectDispensor whose value is an object that has a single method "lookup" that takes a string argument.   When presented with a string key that it it recognizes, it returns the the associated object.  All frames return the same object for any given key.

Given that definition.  How do you make SharedObjectDispensor visible as a global in each frame and how do you make each such global binding have the same shared dispenser object as its value.

Now a variation on the same problem:

SharedObjectDispensor is a a binding that is exported from a module externally named SharedObjects.js.  Other than that it behaves the same as described above.

So, how do you implement SharedObject.js to accomplish that.

----------------------------------

Either of these use cases seem like something that should be easily accomplished, if you are defining the module loaders that set up the frames and control module loading into the frames.

However, if you simply use HTML iframes then you are presumably using an implementation provided module loader that implements the cross-frame sharing rules defined by the html spec.  Can the first approach be accomplished today using iframes?

Bottom lines, symbol sharing is such a specific case of a more general use case.  Solve the general case and you should also have a solution for symbols.


Allen



> 
> 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.
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121006/258ffd7c/attachment.html>


More information about the es-discuss mailing list