Re: [heycam/webidl] Does a non-nullable and non-required dictionary member of interface type make sense? (#176)

One can make the argument for accepting null if the intent of the argument is to pass in a thing that will get stored and returned later.  This allows the thing that gets passed in to be exactly the thing that's stored, and in the particular case of a constructor argument options object may allow an existing object to be used as the options object.  Of course in the case of `AudioBufferSourceNode` in particular that won't work because `detune` and `playbackRate` have different types in the object and the dictionary...  

Anyway, the event init dictionaries by and large follow the above pattern of using null in the dictionary when it's passing through a value that will then get stored in an internal slot on the event and returned from a getter directly.  That covers most of the dictionaries in https://github.com/heycam/webidl/issues/176#issuecomment-248259867

I think HitRegionOptions should not have used a nullable thing, probably.

(Of course one could make the argument that the "stored and returned later" case should _return_ undefined instead of null when there is nothing stored...)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/176#issuecomment-248264292