W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2012

RE: SomethingEventInit dictionaries

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>
Message-ID: <9768D477C67135458BF978A45BCF9B3853A6B0B3@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
> 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC