domenic at domenicdenicola.com (2013-08-05T15:09:10.005Z)
On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller <erights at gmail.com> wrote: > 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. Not exactly -- it's a fresh namespace, so no legacy collisions are possible. Of it immediately becomes a landgrab, similar to npm package names -- or even better, identical to global object today. This is a social problem, and the incentives to play fair have proven effective. This registry would have the secondary effect of functioning as a universal *concept* registry, e.g. [the IANA link relation types][1]. [1]: http://www.iana.org/assignments/link-relations/link-relations.xhtml
On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller <erights at gmail.com> wrote: > 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. > Not exactly -- it's a fresh namespace, so no legacy collisions are possible. Of it immediately becomes a landgrab, similar to npm package names -- or even better, identical to global object today. This is a social problem, and the incentives to play fair have proven effective. This registry would have the secondary effect of functioning as a universal *concept* registry, e.g. the IANA link relation types [1]. [1] http://www.iana.org/assignments/link-relations/link-relations.xhtml -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/38cf29a9/attachment.html>