On Sep 26, 2013, at 7:01 PM, Kevin Smith <zenpars...@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. https://mail.mozilla.org/pipermail/es-discuss/2013-September/033768.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033770.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033771.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033774.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033766.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033756.html https://mail.mozilla.org/pipermail/es-discuss/2013-September/033755.html > - 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... Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
