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

+1 to HTA comments…

On Dec 8, 2013, at 9:27 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> 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.
> 
>

Received on Tuesday, 10 December 2013 18:22:00 UTC