On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> 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. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
