- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Fri, 24 Apr 2009 20:40:03 -0700
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
Received on Friday, 24 April 2009 20:40:03 UTC