Comments on Sept Meeting Notes
dherman at mozilla.com
Thu Sep 26 22:41:15 PDT 2013
On Sep 26, 2013, at 7:01 PM, Kevin Smith <zenparsing at gmail.com> 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