Comments on Sept Meeting Notes

David Herman dherman at mozilla.com
Fri Sep 27 10:02:20 PDT 2013


On Sep 27, 2013, at 8:28 AM, Allen Wirfs-Brock <allen at 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



More information about the es-discuss mailing list