Comments on Sept Meeting Notes

Dean Landolt dean at
Wed Sep 25 09:31:42 PDT 2013

On Wed, Sep 25, 2013 at 12:04 AM, Kevin Smith <zenparsing at> 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: <>

More information about the es-discuss mailing list