domenic at domenicdenicola.com (2013-08-05T15:08:18.153Z)
Where does the w-symbols module come from? Remember that initially w1.1 is
loaded into realm A without knowledge of realm B and vice versa. Let's also
say, to emphasize the point, that they're also under disjoint module
loaders, so at the time they're initialized they can't use a common module
loader as a rendezvous point for new definitions.
> Other options include storing the symbol in some kind of global
> registry (which the module registry is doing above).
I know of only two such notions of a global registry:
* One that would also serve as a global communications channel, which is therefore disqualified
* The equivalent of an interning table, as in the symbol tables of smalltalk that Dean mentions.
An interning table from JS strings to unique symbols would have the
property that
intern(str1) === intern(str2) iff str1 === str2
The cool thing about an such interning table is that it is global mutable
state that does not provide a global communications channel.
To avoid accidental collision on the interned symbols, you must avoid
accidental collision on the strings used as keys in this registration
table. This demands exactly as much collision resistant of string choices
as using the strings directly. And therefore also demands strings which are
just as ugly.
On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote: > One way could be to have a shared module with the symbol that both > w1.1 and w1.2 uses. > > // w-symbols.js > export let foo = Symbol(); > > // w-1.1.js > import {foo} from 'w-symbols'; > ... > > // w-1.2.js > import {foo} from 'w-symbols'; > ... > Where does the w-symbols module come from? Remember that initially w1.1 is loaded into realm A without knowledge of realm B and vice versa. Let's also say, to emphasize the point, that they're also under disjoint module loaders, so at the time they're initialized they can't use a common module loader as a rendezvous point for new definitions. > > Other options include storing the symbol in some kind of global > registry (which the module registry is doing above). > I know of only two such notions of a global registry: * One that would also serve as a global communications channel, which is therefore disqualified * The equivalent of an interning table, as in the symbol tables of smalltalk that Dean mentions. An interning table from JS strings to unique symbols would have the property that intern(str1) === intern(str2) iff str1 === str2 The cool thing about an such interning table is that it is global mutable state that does not provide a global communications channel. To avoid accidental collision on the interned symbols, you must avoid accidental collision on the strings used as keys in this registration table. This demands exactly as much collision resistant of string choices as using the strings directly. And therefore also demands strings which are just as ugly. > > > On Wed, Jul 31, 2013 at 11:03 AM, Mark Miller <erights at gmail.com> wrote: > > This point is important enough that I'm resending as the start of a new > > thread. > > > > > > On Wed, Jul 31, 2013 at 7:50 AM, Mark S. Miller <erights at google.com> > wrote: > >> > >> > >> In thinking about this, I become ever more puzzled about the versioning > >> and inter-realm problems for user-defined unique symbols -- I think it > may > >> be a train wreck. Scenario: Library W version 1.1 defines and uses a > unique > >> symbol @foo which is loaded into realm A. Library W version 1.2 > purposely > >> intends to continue to define and use the "same" unique symbol @foo, so > that > >> W1.2 code can successfully handle instances of W1.1 code. Library W1.2 > is > >> loaded into realm B. The two realms come into contact, and objects from > the > >> two W's come into contact. How did they both coordinate to define and > use > >> the same @foo symbol? > > > > > > > > > > -- > > Cheers, > > --MarkM > > > > -- > erik > -- Text by me above is hereby placed in the public domain Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/7b0a15eb/attachment.html>