Comments on Sept Meeting Notes

Kevin Smith zenparsing at
Tue Sep 24 21:04:34 PDT 2013

> 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.

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

More information about the es-discuss mailing list