Re: Use of "required" dictionary attributes for events

On Tue, Sep 9, 2014 at 7:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Now that we have the idea of "required" dictionary attributes, it seems like
> they can be used to solve a long-lasting pain point with event constructors.
>
> Consider this IDL from the webapps spec:
>
>   dictionary TrackEventInit : EventInit {
>     (VideoTrack or AudioTrack or TextTrack) track;
>   };
>
>   [Constructor(DOMString type, optional TrackEventInit eventInitDict)]
>   interface TrackEvent : Event {
>     readonly attribute (VideoTrack or AudioTrack or TextTrack) track;
>   };
>
> with accompanying prose that says:
>
>   The track attribute must return the value it was initialised to.
>   When the object is created, this attribute must be initialised to
>   null. It represents the context information for the event.
>
> There's an obvious mismatch between the prose and the IDL here: The prose
> wants to init to null, but the IDL wants to claim that null is never
> returned.  Presumably this is because the actual uses of this event in the
> spec then go ahead and set the track attribute to a non-null value... but
> that doesn't help script that uses the constructor; in that situation the
> spec is just self-contradictory.
>
> Gecko resolves this problem at the moment by making the "track" attribute in
> both the dictionary and the interface nullable.
>
> However, now that we have the ability to require attributes in dictionaries
> it seems like we could do:
>
>   dictionary TrackEventInit : EventInit {
>     required (VideoTrack or AudioTrack or TextTrack) track;
>   };
>
> and remove the bits about null, since now the constructor will always have a
> track to work with.
>
> Making the attribute nullable, with a default value of null, means you can
> do this:
>
>   var ev = new TrackEventInit();
>
> without having to pass a dictionary.  On the other hand it also means that
> you can create a TrackEvent with a null track.  Making the attribute
> non-nullable but required means that you have to do something like:
>
>   var ev = new TrackEventInit({ track: something });
>
> to create a TrackEvent, but guarantees that all TrackEvents have a useful
> .track...
>
> Do people have a preference for one or the other of these solutions in
> designing event APIs?  What about other constructor APIs that take
> dictionary arguments?

It doesn't seem particularly useful to initialize a track event
without a track, so I'm fine with making track required and not
nullable.

~TJ

Received on Tuesday, 9 September 2014 14:49:05 UTC