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 <[email protected]> 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 <[email protected]> wrote: > >> On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock <[email protected]> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
