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