- From: David Bruant <bruant.d@gmail.com>
- Date: Mon, 21 Jul 2014 23:08:23 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, www-dom@w3.org
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