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