Anne van Kesteren <mailto:ann...@annevk.nl>
September 30, 2013 6:27 AM
Right, which is why symbols are so nice as HTMLCollection gets around.
Yes, for naming meta-level stuff.
For naming methods, not nice. This limits future additions.
/be
Kevin Smith <mailto:zenpars...@gmail.com>
September 28, 2013 7:14 PM
Anne,
Would you agree that HTMLCollection is an inherently future-hostile
API? That is, it is impossible to add *any* methods or properties to
the API without potentially breaking compatibility?
{ Kevin }
Anne van Kesteren <mailto:ann...@annevk.nl>
September 27, 2013 1:18 PM
During the meeting I tried to make the point that symbols would be
better for objects that have named getters, such as HTMLCollection:
<div id=@iterator></div>
<script>alert(document.getElementsByTagName("div")["@iterator"])</script>
Of course, web compatibility may or may not be impacted here and if
not we may be able to make named getters more complicated by not
looking at @-prefixed strings, but symbols have none of that. We could
of course also not make HTMLCollection iterable, but that seems like a
shame.
Kevin Smith <mailto:zenpars...@gmail.com>
September 26, 2013 7:01 PM
Going to keep this short and sweet:
- 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.
- 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.
- 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.
- 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?
- Perfect (collision avoidance) is the enemy of the good (collision
avoidance).
- Symbols are surprisingly tricky at the spec level. (new Symbol()
throws, what?)
{ Kevin }
Allen Wirfs-Brock <mailto:al...@wirfs-brock.com>
September 26, 2013 6:03 PM
On Sep 26, 2013, at 5:22 PM, David Herman wrote:
Am I not explaining this well? I feel like I've been trying to make this point
several times over in this thread.
probably in a earlier thread of this topic that I did't pay a lot of attention
too.
One of the biggest issues with GUID's -- the thing that makes everyone turn
three shades of green every time it gets proposed -- is the ergonomics. One of
the main complaints people made about symbols was that it's not possible to do
userland coordination across realms. While I don't think we have to solve that
for ES6, my examples demonstrate that with a registry symbols absolutely can
provide cross-realm coordination while tangibly beating out string conventions
for ergonomics/usability/readability.
No the ergonomic issues are good arguments against using GUID for the the actual property
keys. One of the attractions of the "@iterator" form is that it has pretty
good ergonomics. If somebody wanted to use them but not not clutter the actual string
with a name space qualifier (which may be a bit noisy, but is still a lot better than a
GUID) they would have to use a Registry to access a friendly string property key.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
