Comments on Sept Meeting Notes

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Sep 26 16:58:53 PDT 2013


On Sep 26, 2013, at 4:43 PM, David Herman wrote:

> On Sep 26, 2013, at 4:22 PM, Mark S. Miller <erights at google.com> wrote:
> 
>> I am saying collision is an issue, but that it only seems that Symbols solve it because we haven't yet designed the registry. So we should do so first, and then re-examine this question in the context of a concrete registry design.
> 
> I don't think a registry design is necessary for symbols to be useful today.
> 
> But I agree it's a fine thing to consider for future-proofing. Design-wise, it would probably be cleanest to have a single function with a test-and-set semantics. Something like:
> 
>    Symbol.register(stringKey[, friendlyName])
> 
> which registers in cross-realm shared state a new shared symbol registered under the given key, or returns the existing registered symbol if one already exists. This avoids any observable race conditions (except for competing friendlyNames, but that's pretty harmless) in the semantics but allows coordination across realms.

I assume that the "friendlyName" is just the non necessarily unique name that can be attached at a Symbol when it is created.

Agree with the test/and set style for registration, but I think there are also use cases for well known symbol access without registration.  For example, it might be used for feature detection.  So I'd suggest also having:
     Symbol.for(stringKey)

which returns either undefined or the Symbols that was already registered under that name.

> 
> (Specification-wise, it's probably hard to specify the shared state precisely without having constructs like workers in the spec. But maybe it could be given an informal specification that speaks hand-wavily about being "thread-safe.")

I wouldn't expect Symbols to be things that can cross serialization boundaries (such as between workers).  You have to register them on the other side.  This suggests that a serializer might to look to reverse map a symbol to the stringKey that was used to register it:

    Symbol.keyFor(symbol)

returns either a string or undefined if that symbol has not been registered

Allen


More information about the es-discuss mailing list