I do not plan to switch to Map for string-keyed maps. I’ll be using `Object.create(null)` instead.
From: es-discuss [mailto:[email protected]] 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 }
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
