Comments on Sept Meeting Notes

Mark S. Miller erights at
Thu Sep 26 18:01:53 PDT 2013

Hi Yehuda, I think I understand everything on your list except "debugger
friendly names". I agree that seeing a GUID in a debugger is unfriendly,
and I understand why a debugger would not show a Symbol that way. But how
would a debugger show a Symbol? Where does a Symbol's debugger-friendly
name come from?

On Thu, Sep 26, 2013 at 5:41 PM, Yehuda Katz <wycats at> wrote:

> The problem with the String proposals is that these things are not exactly
> Strings. Specifically, we all mostly agree that we want:
> * non-enumerability
> * throw on coercion to String
> * debugger-friendly names
> * some degree of non-collision
> * decent ergonomics, i.e. ability to easily understand that you're looking
> at a collision-resistant key and what it means
> * possibly other semantic distinctions that arise over time
> It's possible to add these features to Strings (which is what we keep
> trying to do), especially with the aid of debugger tools, but it would mean
> shoehorning the semantics into a poorly-defined subset of Strings, and thus
> polluting the semantics of *all* Strings.
> If we want something that's sort of like a String but with a bunch of
> semantic distinctions, let's make a new kind of thing.
> Yehuda Katz
> (ph) 718.877.1325
> On Thu, Sep 26, 2013 at 5:22 PM, David Herman <dherman at> wrote:
>> 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.
>> Dave
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list