My sincerest and deepest apologies for taking us down this dark path and I hope that our friends at Spritely do not object to renaming OCapN Selector back to Symbol as is obviously right and just. Here’s what happened.

@kumavis is implementing OCapN in EndoJS and pushed back on this whole Selector business. This gave me the push I needed to notice something obvious in hindsight. First, some background.

JavaScript has three flavors of Symbol.

• registered symbols Symbol.for(key), which are interned irrevocably forever and always identical for the same key
• well-known symbols like Symbol.asyncIterator, that provided by the language for language protocols only, also live forever, and are unique even across window and iframes in the shared JavaScript memory
• gensyms like Symbol(description), which are unforgeable and get GCd when they’re dropped, but not === equal to each other, even if they have the same description

EndoJS currently supports registered symbols and well-known symbols and we have known this to be a mistake for some time, and it has been deprecated for just as long.

Knowing we couldn’t use symbols for OCapN “selectors” informed my proposal that the reified JavaScript representation of a selector be an object like {[Symbol.for('passStyle'): 'selector', [Symbol.toStringTag]: distributedKey}. This means that selectors are not locally === for purposes of pass invariant equality. You have to use a pass-style convention to compare them.

This means there is no disadvantage of just using Symbol(description) to make disposable copies of OCapN “selectors”. They would be copy-data and subject to the same “always a fresh copy when round-tripped” semantics we have for JavaScript objects and arrays (OCapN structs and lists).

So, we are going to engage in an experiment to confirm that we can just switch our representation of symbols from registered/well-known to unforgeable symbols. We are expecting that experiment to succeed and issuing this advice with an apology, to be presented at our May meeting.