Comments on Sept Meeting Notes

Domenic Denicola domenic at
Tue Sep 24 21:40:52 PDT 2013

I do not plan to switch to Map for string-keyed maps. I’ll be using `Object.create(null)` instead.

From: es-discuss [mailto:es-discuss-bounces at] On Behalf Of Kevin Smith
Sent: Wednesday, September 25, 2013 00:05
To: Tab Atkins Jr.
Cc: es-discuss
Subject: Re: Comments on Sept Meeting Notes

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