[whatwg] Exposing EventTarget to JavaScript

[Garrett Smith]

On Fri, Apr 24, 2009 at 2:59 PM, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>> Erik Arvidsson wrote:
>>>
>>> I do agree that the EventTarget API is suboptimal and so are most of
>>>
>>> the DOM APIs but it is what we got and we need tie the lose ends and
>>> make ends meet.
>>
>> Why is the right approach to this to add addEventListener and its baggage
>> to everything instead of adding a sane API to everything?
>
> What would be a better approach?

Turning an interface into a class doesn't make any sense at all.

EventTarget is an interface.

It would be trivial to create a new DOM object that implements EventTarget.

Boris pointed out that there are some problems with addEventListener.
Lets not ignore those. Trying to shoehorn an existing API to
accomodate new functionality, in light of existing problems sounds
like a bad idea.

EventTarget should not become a Constructor.

You gain a lot from consistency and doing
> something that developers are already intimately familiar with.

Changing EventTarget from an interface into a Constructor would create
less consistency in the behavior of instances implementing (or
Extending) EventTarget, would result in less consistency in the
expected behavior of such objects, and would reduce consistency in the
EventTarget interface (old vs new).

If you want consistency in an API, use a different one. The new one
ignore |useCapture|, so clients wanting to use both could use
duckTyping.

Garrett