- 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>
> 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:
window.SomethingEvent
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