On Sep 27, 2013, at 8:28 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
> On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
>
>> What's the use case for Symbol.keyFor?
>>
>
> The use case was actually suggested in a response to dherman earlier in this
> thread when he mentioned sharing symbols between workers.
>
> If you need to serialize an object with symbol keyed properties you need to
> convert the symbol into sometime that can be equivalently recreated on the
> other side of the serialization barrier. For a registered Symbol the obvious
> way to do this is via its registration name:
>
> Symbol.toJSON = function() {
> let key = Symbol.keyFor(lthis);
> if (key === undefined) return null; //unregistered symbols can't be
> serialized in this example
> return "**Symbol:"+key;
> }
>
>
> The deserializer would have to do a pass over the resulting objects
> replace=ing "**Symbol:..." property names with the locally register Symbol
> under the same key.
Oh, I think I finally understand what you're getting at, and how it avoids any
shared state. Let me summarize, and forgive me for just repeating what you've
already said:
- don't share symbols between workers
- registries are per-worker (in which case there's absolutely nothing needed
from the language mechanism-wise, except to establish conventions)
- use some custom encoding for representing symbolic property names as string
names that contain their registry key
Then workers can coordinate without needing to do any special handshaking or
up-front message-passing, they just register names lazily as they encounter
them in the marshalling/unmarshalling process.
AFAICT this constitutes a complete story for symbol registration that requires
zero new mechanisms in the language (beyond symbols, of course).
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
