Re: Nullable interface members (which cannot be initialized to null by the script)

On 12/05/2013 11:11 AM, Adam Bergkvist wrote:
> Hi
>
> We have a few cases in the spec where interfaces have nullable 
> attributes, but the dictionaries used to initiate these attributes 
> don't have nullable types for the corresponding dictionary members.
>
> I guess the platform could create an object by bypassing the 
> dictionary (and set a value of null), but I think that should be an 
> exception.

Sorry, I don't understand the problem.

The dictionary specification ( 
http://heycam.github.io/webidl/#idl-dictionaries ) says:

On a given dictionary value, the presence of each dictionary member is 
optional.

If a dictionary member used to initialize an attribute is not present, 
it seems to me that the value MUST be null unless the spec says otherwise.

I'm actually worried about the opposite problem: Since events (and other 
things) are initialized from dictionaries, we seem to have no syntax to 
express that a certain field MUST be given a value (such as the stream 
in MediaStreamEvent). But I guess we can express that in prose.

But looking at your examples, I do have opinions for each....

>
> Looking at the first one - I don't think we want a MediaStreamEvent 
> with a null-MediaStream that would need a not-null-check before it can 
> be used. Are any of the other motivated or should I remove the "?" 
> from the attributes from all of them?
>
> /Adam
>
> dictionary MediaStreamEventInit : EventInit {
>     MediaStream stream;
> };
>
> [ Constructor (DOMString type, MediaStreamEventInit eventInitDict)]
> interface MediaStreamEvent : Event {
>     readonly    attribute MediaStream? stream;
> };

In this case, I think the question mark should be removed. A 
MediaStreamEvent without a stream is meaningless.

>
> ==============
>
> dictionary RTCSessionDescriptionInit {
>     RTCSdpType type;
>     DOMString  sdp;
> };
>
> [ Constructor (optional RTCSessionDescriptionInit descriptionInitDict)]
> interface RTCSessionDescription {
>                 attribute RTCSdpType? type;
>                 attribute DOMString?  sdp;
>     serializer = {attribute};
> };

In this case, I think the question mark for "type" is again meaningless. 
We've discussed whether "sdp" should be allowed to be empty (for 
"rollback", for instance), but I don't see a reason to allow it to be 
missing. Two ways of specifying "nothing here" is one too many. I 
suggest we remove the question marks.

>
> ==============
>
> dictionary RTCIceCandidateInit {
>     DOMString      candidate;
>     DOMString      sdpMid;
>     unsigned short sdpMLineIndex;
> };
>
> [ Constructor (optional RTCIceCandidateInit candidateInitDict)]
> interface RTCIceCandidate {
>                 attribute DOMString?      candidate;
>                 attribute DOMString?      sdpMid;
>                 attribute unsigned short? sdpMLineIndex;
>     serializer = {attribute};
> };
>
>

We can remove the question mark on "candidate" if the candidate itself 
is supposed to be NULL in the RTCPeerConnectionIceEvent event, but then 
we need to add it back in the definition of RTCPeerConnectionIceEvent 
(currently section 4.8.2). At the moment, an RTCPeerConnectionIceEvent 
cannot have a null candidate.

The sdpMid and sdpMLineIndex need question marks, because it's supposed 
to be legal to specify only one of them.