Comments on Sept Meeting Notes

Brendan Eich brendan at mozilla.com
Mon Sep 30 09:12:25 PDT 2013


> Anne van Kesteren <mailto:annevk at 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:zenparsing at 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: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
>
>


More information about the es-discuss mailing list