Yehuda Katz (2013-09-27T00:41:49.000Z)
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 mozilla.com> wrote:

> On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock <allen at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/5498815f/attachment.html>
domenic at domenicdenicola.com (2013-10-13T02:37:46.019Z)
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.