Re: Allowing ES6 Symbols as event names

Le 21/07/2014 17:49, Boris Zbarsky a écrit :
> On 7/21/14, 10:20 AM, David Bruant wrote:
>> Very much like symbols can be used as property names, I believe they
>> should be usable as event names.
>
> Will that be backwards-compatible with code that operates on 
> event.name on events today?
(I assume you mean event.type)
hmm... good question. I obviously don't have a definite answer, but some 
elements make me hopeful.
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).
For such code to break, the code would then need to override the native 
addEventListener and have some code which assumes the event name to be a 
string.
This assumption can be true, but in most cases, event names are only 
used for equality (directly with === or indirectly as property name to 
find the relevant listeners, but neither case can cause breakage with 
symbols).
This assumption can lead to a breakage if the code reads the string, for 
instance to search for a prefix. Some libraries have conventions like 
"change:blabla" for event names. But they also usually reimplement their 
own event system, so that wouldn't be a cause for a breakage.

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 (which would probably break more easily if symbols came along).

So in conclusion, code that would break is overriding 
Event.prototype.addEventListener and reading the string, for instance to 
find a prefix. This sounds unlikely enough... but I've seen less horrors 
on the web than you have, so I'm usually more optimistic about these 
things :-)

I briefly looked at jQuery [1] to see if it was using event.type. It 
does only to do === on it or as property key (that's obviously only the 
latest version, I didn't look at other versions, but imagine the story 
is the same). jQuery doesn't override addEventListener as far as I know 
either.
I briefly looked at Flight [2] too given it heavily relies on DOM events 
for component communication and found the same thing.
These are, of course, well-maintained libraries, not necessarily 
representing what's on the web.

David

[1] https://github.com/jquery/jquery/blob/master/src/event.js
[2] https://github.com/flightjs/flight/blob/master/lib/base.js