Kevin Smith <mailto:[email protected]>
September 27, 2013 9:56 PM
<div id=@iterator></div>
<script>alert(document.getElementsByTagName("div")["@iterator"])</script>
This is a good point, and one which I was trying to reason about (way)
upthread. This might do it - have to sleep on it, though...
I took Anne's cheeky lack of quotes around the div's id attribute to be
just good HTML minimal style :-P. No extension there.
In other words, I thought this was an argument against using "@iterator"
to name the unstratified iteration protocol trap.
/be
{ Kevin }
Anne van Kesteren <mailto:[email protected]>
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:[email protected]>
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:[email protected]>
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
David Herman <mailto:[email protected]>
September 26, 2013 5:22 PM
The difference is the ergonomics. The GUID shows up in your developer
tools, when you introspect on the property names, etc. The symbol
shows up as a symbol, which is conceptually cleaner and vastly more
readable. If you have 5 different GUIDs in your object, and you
inspect the object in developer tools, you have to go and manually
look up which one corresponds to which abstraction. Or if you use a
human-readable but mildly obfuscated name, then you need a naming
convention, and then you have the collision problem all over again.
Finally, you can use an obfuscated GUID-y suffix but with a
human-readable prefix, so at least humans have some hope of reading
it, but you've still made your users' lives unpleasant.
With symbols you give all your users the pleasant experience of a
clean distinction between symbol and string. And with some sort of
registry, you can provide an abstraction that registers the symbol so
that multiple realms can even coordinate on the symbol even in the
face of multiple distinct copies of the library.
Am I not explaining this well? I feel like I've been trying to make
this point several times over in this thread. 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.
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
