It seems like a mixin. I guess it'd be less compatible, but what about changing `: XHRET` to `implements XHRET`?

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.

(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.

At some point Olli argued for the common prototype I think. I don't really care either way.

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.

If I turn it into a mixin, would I have to change both XMLHttpRequest and XMLHttpRequestUpload to directly inherit from EventTarget?

Yes.

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.

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.

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.)

> 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.

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

Right, but Node actually adds functionality.

onfoo event handlers are functionality.

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.

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.

onfoo isn't really functionality. It's just syntax sugar.

(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...

(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.)

(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?

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.