On Sep 26, 2013, at 4:43 PM, David Herman wrote:
> On Sep 26, 2013, at 4:22 PM, Mark S. Miller <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
