Comments on Sept Meeting Notes

Brendan Eich brendan at mozilla.com
Sat Sep 28 10:43:47 PDT 2013


> Kevin Smith <mailto:zenparsing at gmail.com>
> 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:annevk at 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:zenparsing at 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:allen at 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
>
>
> David Herman <mailto:dherman at mozilla.com>
> 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
>
>


More information about the es-discuss mailing list