27823 2015-01-13 20:16:42 +0000 We should consider dropping [NoInterfaceObject] from XMLHttpRequestEventTarget 2015-01-16 08:39:34 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC All RESOLVED FIXED P2 normal --- 1 bzbarsky annevk bugs d jonas mike public-webapps public-webapps-bugzilla oldest_to_newest 117095 0 bzbarsky 2015-01-13 20:16:42 +0000 Doesn't seem to be a good reason for it. 117096 1 d 2015-01-13 20:21:24 +0000 It seems like a mixin. I guess it'd be less compatible, but what about changing `: XHRET` to `implements XHRET`? 117097 2 bzbarsky 2015-01-13 20:26:30 +0000 That would be possible. It'd mean that .upload and the XHR itself no longer share a prototype for their common set of event handlers, but apart from that would not be an issue in any way. 117131 3 jonas 2015-01-14 02:59:46 +0000 (In reply to Domenic Denicola from comment #1) > It seems like a mixin. I guess it'd be less compatible, but what about > changing `: XHRET` to `implements XHRET`? This was my first thought too. 117136 4 annevk 2015-01-14 07:11:18 +0000 At some point Olli argued for the common prototype I think. I don't really care either way. 117152 5 bugs 2015-01-14 12:34:06 +0000 Dealing with the same prototype chain can be handy - especially since the prototype would be used only with XHR stuff. EventTarget is then shared with random other stuff too. Mixin is kind of a weaker abstraction - or how to say - and since there really isn't reason to use that, I'd just remove [NoInterfaceObject]. But don't feel very strongly about this. 117154 6 annevk 2015-01-14 12:54:07 +0000 If I turn it into a mixin, would I have to change both XMLHttpRequest and XMLHttpRequestUpload to directly inherit from EventTarget? 117155 7 bzbarsky 2015-01-14 13:03:49 +0000 Yes. 117156 8 annevk 2015-01-14 13:15:16 +0000 https://github.com/whatwg/xhr/commit/2c56fdc97b65dfe4026fab8ceb78a7fb9bddeb87 I decided to not turn it into a mixin as the inheritance design seems more compatible with how we deal with EventTarget. 117158 9 d 2015-01-14 15:59:44 +0000 I don't care strongly, but I'd be curious to understand what you mean by "the inheritance design seems more compatible with how we deal with EventTarget." Lots of things inherit directly from EventTarget and have corresponding properties for their `onxxx` methods. 117159 10 annevk 2015-01-14 16:52:58 +0000 My rationale was that for the common functionality provided by EventTarget we wanted to inherit rather than create a mixin and that therefore we should inherit for the common functionality provided by XMLHttpRequestEventTarget as well. If XMLHttpRequestEventTarget should be a mixin, why shouldn't EventTarget? (Ian argued it should.) 117164 11 d 2015-01-14 19:27:04 +0000 > My rationale was that for the common functionality provided by EventTarget we wanted to inherit rather than create a mixin and that therefore we should inherit for the common functionality provided by XMLHttpRequestEventTarget as well. I still don't get it. What common functionality is provided by XMLHttpRequestEventTarget that is not already provided by EventTarget? It seems more like it's just working around the awkard need to add onX for all the events. Stated another way, most classes that fire events have a very simple hierarchy: they inherit from EventTarget, and have onX properties on their own prototype. However, XMLHttpRequestUpload and XMLHttpRequest are now exceptions to that rule. 117165 12 annevk 2015-01-14 20:48:04 +0000 I don't think that's true, e.g. everything in DOM inherits from an abstract interface as well that in turn inherits from EventTarget: *SpecificNode* : Node : EventTarget 117166 13 d 2015-01-14 20:51:55 +0000 Right, but Node actually adds functionality. 117167 14 bugs 2015-01-14 20:57:12 +0000 onfoo event handlers are functionality. 117168 15 d 2015-01-14 21:01:43 +0000 I guess that's the divergence. They feel more like... syntax, almost. Something that, in a better world, would just automatically work for all EventTargets. 117190 16 jonas 2015-01-15 06:32:00 +0000 I think the simplest solution is to simply get rid of XMLHttpRequestEventTarget and add the corresponding on* properties to the XMLHttpRequestUpload and XMLHttpRequest interfaces. That's essentially how the rest of the DOM works. The XMLHttpRequestEventTarget interface seems like a feature without use cases. 117191 17 jonas 2015-01-15 06:33:21 +0000 onfoo isn't really functionality. It's just syntax sugar. 117195 18 annevk 2015-01-15 08:45:24 +0000 (In reply to Jonas Sicking from comment #16) > I think the simplest solution is to simply get rid of > XMLHttpRequestEventTarget and add the corresponding on* properties to the > XMLHttpRequestUpload and XMLHttpRequest interfaces. That's essentially how > the rest of the DOM works. Not really. If we can't use inheritance we use mixins. > The XMLHttpRequestEventTarget interface seems > like a feature without use cases. If you want to extend both XMLHttpRequest and XMLHttpRequestUpload it's the way to go. If only Olli and I feel this way and you see us generating on* attributes "automatically" at some point, I guess I'm willing to turn this into a mixin after all... 117206 19 bugs 2015-01-15 11:05:47 +0000 (In reply to Jonas Sicking from comment #17) > onfoo isn't really functionality. It's just syntax sugar. Unfortunately onfoo can be very much more than that, as in case of MessagePort's onmessage. (I consider it a bug that MessagePort.onmessage behaves differently to any other onfoo in the platform.) 117262 20 jonas 2015-01-16 01:42:48 +0000 (In reply to Anne from comment #18) > (In reply to Jonas Sicking from comment #16) > > I think the simplest solution is to simply get rid of > > XMLHttpRequestEventTarget and add the corresponding on* properties to the > > XMLHttpRequestUpload and XMLHttpRequest interfaces. That's essentially how > > the rest of the DOM works. > > Not really. If we can't use inheritance we use mixins. Lots of interfaces have onfoo's directly on them. Like Window and WebSocket. But yes, I'd be fine with using mixin's too. > > The XMLHttpRequestEventTarget interface seems > > like a feature without use cases. > > If you want to extend both XMLHttpRequest and XMLHttpRequestUpload it's the > way to go. What's the use case? (In reply to Olli Pettay from comment #19) > (In reply to Jonas Sicking from comment #17) > > onfoo isn't really functionality. It's just syntax sugar. > > Unfortunately onfoo can be very much more than that, as in case of > MessagePort's onmessage. Sure, but that's not the case here, no? 117270 21 annevk 2015-01-16 08:39:34 +0000 Window and WebSocket are completely orthogonal classes. They are not expected to share functionality. XMLHttpRequest and XMLHttpRequestUpload are both event targets and share a whole bunch of events. I don't see why that is so different from say Text and Comment sharing CharacterData. Your argument is that on* is syntax, but that is not always the case as Olli points out, so it's unclear whether we could ever make it so. As for common functionality, a library could support an additional event of sorts and want to expose an on* member on both classes. If this should be a mixin, then lots of stuff in the DOM and especially EventTarget should have been made a mixin too.