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 05:12:42 +0000
To: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853A6A9D3@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> The draft currently includes an interesting pattern (thanks Yang for
> inadvertently reminding me of this) for declaration of Event classes.
> It goes like this:
> [Constructor(SomethingEventInit data)]
> interface SomethingEvent : Event {
>     readonly attribute Something attr;
> }
> dictionary SomethingEventInit {
>     Something attr;
> }
> After having actually implemented most of this stuff, most of the time it
> is sufficient (in JavaScript at least) to instantiate Event and tack the
> necessary attributes on.  Even in a formal sense, the SomethingEventInit
> object has no need to be in the public namespace, let alone the
> specification.  I can understand why the internals of your implementation
> might use these, but are really just browser internals.  Applications
> don't need either definition.  Why isn't the pattern like so?

It's not quite just browser internals. The constructable Event is exposed as an object to script as:


so that new SomethingEvent() can be called on it and dispatched with object.dispatchEvent().

However, what's missing above is the inheritance of the dictionary. It should be:

dictionary SomethingEventInit : EventInit

This lets you assign values to all the readonly attributes on the regular event and/or other derived classes.
Received on Friday, 19 October 2012 05:14:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:34 UTC