- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Wed, 24 Oct 2012 20:54:39 +0000
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Oct 18, 2012, at 11:12 PM, Travis Leithead <travis.leithead@microsoft.com> wrote:
>> 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.
Even if it is a bit weird, I like the principle of least surprise. So if developers are used to seeing this done one way, I'd sort of prefer to do it the way they are used to in other web APIs.
Received on Wednesday, 24 October 2012 20:55:07 UTC