Comments on Sept Meeting Notes

David Herman dherman at
Thu Sep 26 22:41:15 PDT 2013

On Sep 26, 2013, at 7:01 PM, Kevin Smith <zenparsing at> wrote:

> - Enumerability?  Yawn...  Enumerability of user-created meta-level method names is fine and should be expected, just as we expect enumerability of "_"-prefixed method names today.

Whether you personally use it, for-in is a reality. Introspection of objects happens, so if you ship a library that's putting meta-level properties into objects it needs to make them non-enumerable to be robust in the face of client code that uses for-in but isn't prepared to understand the meta properties.

> - Duck typing *must* work across Realms.  Symbols without a registry do not.  You can make special cases for built-in symbols, but special cases make bad law.

Symbols are absolutely future-proof for a registry. If we don't solve all use cases today, we keep working to improve the language and address more use cases. Someone I know recently made the point that the perfect is the enemy of the good...

> - If you are going to use a symbol registry, then you really need to prove how that is any better than just using the registry key itself.

Between Yehuda and me I count 7 times that we've addressed this point in this thread.

> - Is getting a symbol with (1) a GUID and (2) a friendly name, then (3) toting that object around really more ergonomic than just using a string literal?

Once again, read the above links. You aren't distinguishing between the ergonomics of the *provider* of a symbol and the *consumer* of a symbol, and it's the latter case that matters. The ergonomics are better for the consumer of a symbol than that of an obfuscated string, especially when working with developer tools or code that manipulates the key and ends up surfacing the obfuscated string.

> - Perfect (collision avoidance) is the enemy of the good (collision avoidance).

Being more likely to break isn't actually a *virtue* so I don't think there's really anything to respond to here.

> - Symbols are surprisingly tricky at the spec level.  (new Symbol() throws, what?)

Come on now. Auto-wrapping of primitives for method calls is a well-understood part of JS, but the wrapped objects themselves are not particularly useful and can be an attractive nuisance.

And here I want to second Yehuda's point: we're talking about a different kind of concept than strings, so it deserves a different language feature. Excessive language parsimony just results in more complexity for the programmer. We've seen this movie before: arrays are just objects, integers are just doubles, environment records are just objects...


More information about the es-discuss mailing list