Re: Allowing ES6 Symbols as event names

Le 22/07/2014 04:11, Boris Zbarsky a écrit :
> On 7/21/14, 5:08 PM, David Bruant wrote:
>> One thing we're sure of is that no existing code today both uses Symbols
>> and assumes that event.type is a string (because Symbols don't exist),
>> so we're guaranteed that no code on the web would break by allowing
>> symbols to be used as event names. That's enough for backward
>> compatibility, no?
>
> Maybe I didn't express my mail very carefully...
>
> If on() did not have that regexp bit in it, then calling on() with a 
> Symbol would succeed, because it would just call right on through to 
> addEventListener.
Why would someone use a symbol as first argument of .on, though?
The feature isn't documented. Right now, it's very clear that the first 
argument is a string http://api.jquery.com/on/

> But then when the event actually happens some parts of jQuery would fail.
But you stepped out of the documentation, you know the risks.
Right now, if you pass a boolean to .on, you get the same error while 
booleans are accepted as first argument of addEventListener (implicitly 
converted to string). I wonder what is so different about symbols.

> So anyone using this API who suddenly starts to see events come 
> through with Symbol-valued names would have their code break.
>
>> But I don't understand why it comes under consideration about
>> whether the native API should allow something or not.
>
> Just because there's a compat risk.  Definitely so for the catch-all 
> event listeners browser extensions can do
Very much like browser extensions need to account for other new features 
(proxies, Maps, etc.).
Why is this compat risk different/worse?

> and for any code that uses a library in this way and then has 
> something else dropped into the page that uses Symbol-named events.
I don't understand this part. I read 3 parties :
* your code
* some library code your code uses and depends on
* third-party code (potentially from a different domain)

The third-party code uses Symbol-named events (with addEventListener 
since the library doesn't support them). But I don't understand how 
either it affects your code or depends on the library compatibility.
The third party code is just leaving its life after symbols like it was 
doing before with you having very little control over its activity.

>
>>> And note that some browser extension systems do in fact provide such a
>>> capability.
>> They'll need to evolve too, very much like browsers evolve their
>> devtools to acknowledge the presence of symbol properties on objects.
>
> Evolving an API is easy.  Evolving extensions that are using it...
I wonder how much this should be worried about.
I understand why browsers don't want to change APIs that would cause 
breakage of existing code that is served on the web. But I don't 
understand the reluctance to change an API that can only break new code.
If symbols are accepted as event names, people will use the native 
versions, libraries will either already work for that or they won't and 
adapt later.

That's the good thing about adding something new, it doesn't break 
anything existing. Things break only if they use the new thing with old 
code, but if that's an issue, then the language can never evolve, can it?

>> Back to your original question I think that backwards-compatibility
>> cannot be an issue by definition since symbols don't exist yet on the
>> web.
>
> I think we simply disagree on what sorts of breakage are acceptable.
Until people use it, there is no breakage. And people have no good 
reason to use it if it's not a documented feature by the library they use.

> Or actually...
>
> Maybe we disagree on how acceptable it is for use of a new feature to 
> be a footgun.  For this particular feature, you have to make sure that 
> every library included by your page, and all your other generic event 
> dispatching/handling code (of which there is a good bit on the web), 
> has been taught about it, right?  And you need to make sure that this 
> happens before _any_ script you include uses the feature. 
Yes. First reasonable thing to do would be to check whether the 
libraries you include do support this Symbol thing. If the answer is 
yes, find, if the answer is no, don't use it yourself. If the library 
hasn't had the time to consider it, then you can try and see if it works 
for you or wait for the new library version, or fallback to using the 
native APIs.

Speaking of footguns, this sort of consideration is even worse when it 
comes to proxies. ES5 objects have plenty of things people expect from 
them (like "the value between two consecutive reads doesn't change") 
that are completely broken with proxies.
And passing proxies with various handlers to libraries will cause the 
same sort of breakage you're talking about. How is this different?

David

Received on Tuesday, 22 July 2014 08:41:36 UTC