Comments on Sept Meeting Notes

David Herman dherman at
Thu Sep 26 17:22:32 PDT 2013

On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock <allen at> wrote:

> I meant, if you didn't have symbols you could pretty much do the same thing by exporting a name that is bound to the GUID string as its value.  That exported name could be imported by clients and used as the friendly way to refer to that property name, just like you are suggesting they do with Symbol values. 

The difference is the ergonomics. The GUID shows up in your developer tools, when you introspect on the property names, etc. The symbol shows up as a symbol, which is conceptually cleaner and vastly more readable. If you have 5 different GUIDs in your object, and you inspect the object in developer tools, you have to go and manually look up which one corresponds to which abstraction. Or if you use a human-readable but mildly obfuscated name, then you need a naming convention, and then you have the collision problem all over again. Finally, you can use an obfuscated GUID-y suffix but with a human-readable prefix, so at least humans have some hope of reading it, but you've still made your users' lives unpleasant.

With symbols you give all your users the pleasant experience of a clean distinction between symbol and string. And with some sort of registry, you can provide an abstraction that registers the symbol so that multiple realms can even coordinate on the symbol even in the face of multiple distinct copies of the library.

Am I not explaining this well? I feel like I've been trying to make this point several times over in this thread. One of the biggest issues with GUID's -- the thing that makes everyone turn three shades of green every time it gets proposed -- is the ergonomics. One of the main complaints people made about symbols was that it's not possible to do userland coordination across realms. While I don't think we have to solve that for ES6, my examples demonstrate that with a registry symbols absolutely can provide cross-realm coordination while tangibly beating out string conventions for ergonomics/usability/readability.


More information about the es-discuss mailing list