[whatwg] Exposing EventTarget to JavaScript

[Boris Zbarsky]

Alex Russell wrote:
>> 2)  It's not clear what the enumeration should actually return.
>>    EventListener objects?  JS Function objects?  Something else?
>>    Last I checked people couldn't even agree on this (both have
>>    pros and cons).
> 
> Array of function objects.

What about event listeners that are not backed by a JS function?  Say 
actual objects in JS with a handleEvent function, or listeners 
implemented in other languages?

>> And other than a debugger, I have yet to see a usecase for this.  Do you
>> have a specific one in mind?
>>
>>> Even in the XHR case, adding more than one listener is currently a
>>> pain.
>> How so, exactly?
> 
> Aaron's note about addEventListener solves it, but in the common case
> where a JS system wants to have multiple callbacks, they either wind
> up carrying around their own event listener system (e.g.,
> dojo.connect()) or a Deferred pattern to wrap functions which only
> support direct dispatch from a single call site.

It's still not clear to me what that has to do with the questions I asked...

>> The only natural thing in DOM is the event flow from target to root. That
>> concept doesn't make much sense in the absence of a linear data structure
>> (the list of ancestors, here).
> 
> I think what I'd like to see is a way for this interface to allow
> arbitrary JS object to specify what their "ancestor" is. That way
> hierarchical JS objects can dispatch "up".

OK.  That makes some sense, assuming that the common case is that there 
is in fact at most one "ancestor".  I don't have any data on whether 
this is the common case; is it?

>> Is your real use case just to call a bunch of listeners in a defined order?
...

> Other systems have similar conveniences, but in general they all exist
> to keep developers from needing to do:
> 
> (function() {
>    var old_happened = thinger.happened;
>    thinger.happened = function() {
>        // ...
>        return old_happened.apply(this, arguments);

That still doesn't answer my question.  You need such chaining in the 
DOM, say, if you use the on* properties.  But if you addEventListener, 
you can have multiple listeners for a given event.  The only caveat is 
that dispatch order is undefined.  So again, is the goal to have 
multiple listeners per event, or to be able to enforce a specific 
ordering on them?  If the latter, would simply requiring dispatch in 
addition order (which is, after all exactly what your example above 
does) be sufficient?

> This method of building "callbacks" on existing APIs is not, to use
> your word, "sane".

Oh, absolutely agreed.

-Boris