Re: Allowing ES6 Symbols as event names

Le 21/07/2014 19:01, Boris Zbarsky a écrit :
> On 7/21/14, 12:19 PM, David Bruant wrote:
>> For such code to break, it would need to be faced with events which is
>> symbole-named. This cannot happen via addEventListener (since it's 
>> currently impossible to listen to events with a symbol name).
>
> But this is the part you're proposing to change, right?
>
> Think library code that basically calls through to addEventListener 
> but also does some stuff with the event before handing it to the 
> library consumer.  jQuery's on(), say.
But it's fairly normal for this code to break when being passed symbols. 
Very much like jQuery can only be expected to fail at properly iterating 
over ES6 Maps and Sets, but that shouldn't prevent them from being added 
to the language in my opinion.
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?

Of course, if symbols-as-event-names becomes a feature in browsers, 
libraries like jQuery will need to evolve to support Symbols, very much 
like it probably needs to improve its $.each to support ES6 Maps and 
Sets. But I don't understand why it comes under consideration about 
whether the native API should allow something or not.

I understood your question as whether code would break because it 
assumes native DOM only supports strings as event names.
Most of the rest of the exchange was based on the difference in 
understanding of the question so I'm skipping it.

>> Above, I started the reasoning with addEventListener, because the DOM 
>> doesn't have, for instance, a mechanism to listen to all events of a 
>> given object
>
> Though people do keep asking for it.
That'd be handy in some cases indeed.

> 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.

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. It's more a question of whether existing code is forward-compatible 
with new ES6 constructs (symbols, proxies, maps, etc.) without 
additional work. Spoiler alert: it is usually not (as you pointed out in 
your message).
But it's not a reason to not add these constructs, nor spread their use 
across the platform when considered relevant (very much like what 
happened with objects with indexed properties which are for-of iterable 
or with the clone algorithm adding support for Map and Set).

David

Received on Monday, 21 July 2014 21:08:51 UTC