- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Fri, 19 Oct 2012 16:24:11 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
> From: Martin Thomson [mailto:martin.thomson@gmail.com] > > On 18 October 2012 22:12, Travis Leithead <travis.leithead@microsoft.com> > wrote: > > window.SomethingEvent > > > > so that new SomethingEvent() can be called on it and dispatched with > object.dispatchEvent(). > > Interesting. For a large class of events in WebRTC, I don't see this > as a realistic scenario. I realize that synthesis of a "click" event > is potentially desirable. Is the accepted practice to extend that > capability to all types of event? Is that still true if the necessary > input cannot possibly be available to the application? It is pretty standard convention. There's always the opportunity to break with tradition, but I think you'll get this same feedback from others when you publish. If you choose not to provide the constructor on the derived event you should be prepared with a good reason (which I think you started to allude to above). A common alternative pattern is to provide the extra data on an object and use events to signal that the data is available. In that case, you only need to use the basic Event and it's not necessary to extend it.
Received on Friday, 19 October 2012 16:25:15 UTC