domenic at domenicdenicola.com (2013-10-13T02:24:23.690Z)
You call namespaced strings "more convenient than symbols, serves the purpose equally well". These two things are obviously not equivalent -- namespaced strings are obviously weaker. We could use them today, yet hardly anyone does this, because it's inconvenient in it's own ways. Yet name collisions happen all the time in the wild, even with ad hoc namespaces, and this is the problem symbols completely solve. Ad hoc namespaces *can't* solve the collision problem and obviously *don't* solve convenience problem -- if they did, we'd already be using them.
On Wed, Sep 25, 2013 at 12:04 AM, Kevin Smith <zenparsing at gmail.com> wrote: > > This seems like a non-sequitur. Symbols aren't meant to help with the >> "object as map" use-case, and even if you tried to, they work terribly >> for it. They're meant for the "add an actual property/method without >> collision" use-case. Again, Maps seem like a non-sequitur here - >> using a Map doesn't aid with avoiding collisions. >> > > Before Maps, I might use a regular object to store arbitrary > string-to-value mappings. Say I'm counting the occurrences of terms > appearing on es-discuss. The key "std:iterator" might actually occur. In > that case we would have a collision with my proposed meta-level property > name. But going forward, no one's going to use a regular object for > arbitrary string keys - it's simply too error-prone. They'll use a Map > instead. Which means that we don't have to worry about arbitrary string > keys colliding with meta-level property names. > > Now, one might argue that using the string "std:iterator" (or equivalent) > would present a backward compatibility hazard for legacy code using objects > as maps. I'll have to think about that one... > > The argument is that, once you take out arbitrary string keys (as occur > when using an object as map), a "namespaced" string provides sufficient > collision resistance to make symbols unnecessary. > > >> How is this in any way better than: >> >> class C { >> std_iterator() { ... } >> } >> >> > The set of non-identifiers is less commonly used for member names by far, > so it has that advantage. But I'm not really saying that "std:iterator" is > better than "std_iterator". I'm saying that both are a simpler solution > than symbols. > You call namespaced strings "more convenient than symbols, serves the purpose equally well". These two things are obviously not equivalent -- namespaced strings are obviously weaker. We could use them today, yet hardly anyone does this, because it's inconvenient in it's own ways. Yet name collisions happen all the time in the wild, even with ad hoc namespaces, and this is the problem symbols completely solve. Ad hoc namespaces *can't* solve the collision problem and obviously *don't* solve convenience problem -- if they did, we'd already be using them. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/8f3ed8ff/attachment.html>