This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was discussed on the webapps list I believe. We should try to include EventTarget in the prototype chain on all objects that are event targets. This way people can modify the EventTarget prototype object to add API to all event targets. A similar modification was done in the DOM Core spec where Node now inherits EventTarget and in the XHR spec where XHR now inherits EventTarget.
That makes no sense. EventTarget is just something that Workers support, it's not what they are. A Worker is not a kind of EventTarget.
> A Worker is not a kind of EventTarget. Why not?
All other specifications that define EventTargets are putting them on the prototype chain. DOM Core[1], indexedDB[2], and XHR[3] already does this. Further, it actually makes it possible to extend the EventTarget interface which is a good thing (for example it lets people implement the "enumerate all registered listener API which is asked for every now and then by overriding add/removeEventListener). [1]http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-node [2]http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-api [3]http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-xmlhttprequest-interface We're planning on making the same change to other interfaces, like FileReader and WebSocket in Firefox.
EventTarget is a service provided by these objects, these objects are not a kind of EventTarget. Suppose these interfaces were TransferrableData, as well. Should they inherit from both EventTarget and TransferrableData? This is an antipattern. There's nothing special about EventTarget here, it's just an interface that these objects provide, it's not key to their existence.
> This is an antipattern. There's nothing special about EventTarget here, it's > just an interface that these objects provide, it's not key to their existence. To make Workers do something useful, it is absolutely must that they are EventTargets (otherwise event handling wouldn't work). And why would Workers related object behave in a different way than other EventTargets?
They don't, they behave the same as Window, ApplicationCache, EventSource, WebSocket, MessagePort, TextTrack, TextTrackCue, MediaStream, PeerConnection, and indeed everything else until recently. I don't understand why EventTarget is special here. > To make Workers do something useful, it is absolutely must that > they are EventTargets (otherwise event handling wouldn't work). It's also imperative that they have the WorkerUtils stuff, but they don't inherit from that either.
(In reply to comment #6) > They don't, they behave the same as Window, ApplicationCache, EventSource, > WebSocket, MessagePort, TextTrack, TextTrackCue, MediaStream, PeerConnection, > and indeed everything else until recently. I think all of these should inherit EventTarget and indeed we'll be making that change going forward in Firefox. > I don't understand why EventTarget is special here. I'm not sure I understand this question. Did you mean to ask why Workers are special? If so, they're not. > > To make Workers do something useful, it is absolutely must that > > they are EventTargets (otherwise event handling wouldn't work). > > It's also imperative that they have the WorkerUtils stuff, but they don't > inherit from that either. Indeed, inheriting from EventTarget isn't needed to make things work. It just makes things cleaner. The proposal that has been happening on the webapps list is that we should stop treating EventTarget as a "service" and instead make objects be EventTargets. This has several advantages, such as: * Ability to modify the EventTarget prototype object in order to add API on all event targets. * Ability to test if an object is an EventTarget by using instanceof * Less confusing "magic" which maps properties into surprising places in the prototype chain. I.e. the interfaces in the spec maps more directly to real API in the scripting environment which makes the spec easier to read and understand. In general, the use of "mixin interfaces" is a bad thing and good to avoid as much as possible. Especially in cases where the interfaces provide API (which isn't the case with TransferrableData for example). Indeed, we can't always avoid them, though we can use them to a much lesser extent than they are used now. (Related to that I'd much prefer to have workers get rid of WorkerUtils, NavigatorID and similar use of mixin interfaces and instead properly write out what the interfaces look like. But that's a different bug).
Oops, meant to reopen as well.
Suppose Transferable gets some members. Why should MessagePort inherit from EventTarget instead of Transferable? Why is EventTarget special here?
Because we can only choose one, and we're choosing EventTarget as that's a much more prevalent interface. In fact, as interfaces go it's the most common one across specs. One good sign is that it fits really well in all instances. For example we never end up with multiple interfaces in a chain that both say that they implement EventTarget.
Just picking one interface based on its current usage to be inherited from really doesn't seem like sane OOP API design to me. What if three years from now we invent a new feature that is implemented by even more interfaces? This seems very short-sighted to me.
That seems like an argument to never make any interface the base of another one. For example maybe Node shouldn't have been the base interface for Element/Text/ProcessingInstruction/Comment/Document. It's entirely possible that a few years from now we'll want to add some functionality to all Elements, Windows and IDBRequests which would have made a great base for those interfaces. After all, you can think of "being able to participate in the Node-tree" as as much a service as "being able to fire events at" is. We can't ever know for sure what we'll want to do in the future. But we can look at what we're doing now and what current trends are. And that data points to EventTarget being a good base for a wide range of objects.
No, not at all. An Element is a Node, that is intrinsic to its entire being. It being able to handle events is a service it provides, but it's not intrinsic to being an Element.
(In reply to comment #13) > No, not at all. An Element is a Node, that is intrinsic to its entire being. It > being able to handle events is a service it provides, but it's not intrinsic to > being an Element. How exactly are you making this distinction?
To me, the reason to have workers ultimately inherit from EventTarget is less a meta-question of "service" versus "is-a"-relationahip, and more a question of ease-of-use for web developers. Given the bindings described by WebIDL, "service" bindings create copies of APIs, whereas common inheritance provide single API entry-points. Like Jonas described above, making all objects that support Event subscription inherit from EventTarget simplifies the web developer's ability to capture and override that functionality from a single choke-point. Otherwise, the web developer has to track down all those separate objects you listed previously and override each one. The trouble with Transferrable, of course, is that making Transferrable inherit from EventTarget paints you into the corner because then _any_ transferrable type (ArrayBuffer, MessagePort, etc.) would have to support EventTarget. :)
Fair enough.
Checked in as WHATWG revision r6378. Check-in comment: Move the Web to a world where things that implement EventTarget just inherit from it. I, for one, now welcome our new EventTarget overlords. http://html5.org/tools/web-apps-tracker?from=6377&to=6378