Use of "required" dictionary attributes for events

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?

-Boris

Received on Tuesday, 9 September 2014 14:18:09 UTC