[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Erik Arvidsson wrote:
>>
>> To help out with this scenario
>> it would be good if an implementation of the EventTarget interface
>> could be exposed to JavaScript.
>
> Why do you want the eventTarget interface as opposed to a sane callback
> function registration setup?
>
>> The next and more important step is to allow a JavaScript "class" to
>> extend an EventTarget. For example:
>>
>> function MyClass() {
>>  EventTarget.call(this);
>>  ...
>> }
>> MyClass.prototype = new EventTarget; // *[1]
>
> So this already works, no?
>
>> One more thing needs to be mentioned and that is how event propagation
>> should work in scenario. If the object has a "parentNode" property
>> then the event dispatching mechanism will do the right thing.
>
> What, precisely, is the use case for this in general?  In the DOM,
> propagating events to parents makes sense (esp. because parents are unique).
>  What would be the use case in a general object graph?

Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.

>> There is one more thing that needs to be done to make this work
>> without a hitch and that is to allow "new Event('foo')" to work.
>> Without that we would still have to do "var $tmp =
>> document.createEvent('Event'); $tmp.initEvent('foo')" which of course
>> is very verbose and requires a document.
>
> Possibly for good reasons?  In some implementations the document is in fact
> baked into the event for various security purposes.

I think individual call sites overriding their dispatch is sane, but
hopefully uncommon.

>> I see this as a small step to make JS and DOM work better together and
>> I hope that "this is the beginning of a beautiful friendship".
>
> It's not really clear to me what the benefits of using the (rather
> suboptimal, from the JS point of view) DOM EventTarget API for generic JS
> callback dispatch are.

I don't think the proposal would be to use it as-is. Clearly it needs
beefing up to serve as a good aspect system for JS, but it's the right
starting place. Treating function calls as message sends or events to
be dispatched gives you a nice way of building after-advice into JS
objects, and with a little bit of massaging, could also give you
before and around advice. There's some friction between the Event
object and the "arguments" object, but not so much that it would be
insurrmountable to recast DOM event dispatch as sub-case of regular JS
function calling. JS libraries provide ways to try to unify these
interfaces (at huge expense), so moving it into the language makes the
most sense.

Regards