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