RE: [WEBIDL] nullable dictionary members
Thanks for the comment, Boris! Jungkee -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, August 16, 2012 3:26 PM To: public-webapps@w3.org Subject: Re: [WEBIDL] nullable dictionary members On 8/15/12 10:05 PM, Jungkee Song wrote: Having said that dictionary members are inherently optional by definition, is it meaningful (and valid) to mark optional fields as nullable? Seems like it should be to me, yes. dicationary Foo { DOMString iWantToBeRequired = Default; DOMString? iWantToBeNullable; DOMString iAmAlreadyOptional; }; Do the two dictionary members iWantToBeNullable and iAmAlreadyOptional semantically make any difference? Yes. The latter can either be unset or set to a string. The former can be unset, set to a string, or set to null. Those are different things. I was thinking spec writers sometimes encounter situations where they would like to explicitly describe certain dictionary members are required while others are not. Dictionaries can't have a required member via IDL, unless the member has a default value Of course the prose can always call for throwing if a member is not set. -Boris
Re: [WEBIDL] nullable dictionary members
On 8/15/12 10:05 PM, Jungkee Song wrote: Having said that dictionary members are inherently optional by definition, is it meaningful (and valid) to mark optional fields as nullable? Seems like it should be to me, yes. dicationary Foo { DOMString iWantToBeRequired = Default; DOMString? iWantToBeNullable; DOMString iAmAlreadyOptional; }; Do the two dictionary members iWantToBeNullable and iAmAlreadyOptional semantically make any difference? Yes. The latter can either be unset or set to a string. The former can be unset, set to a string, or set to null. Those are different things. I was thinking spec writers sometimes encounter situations where they would like to explicitly describe certain dictionary members are required while others are not. Dictionaries can't have a required member via IDL, unless the member has a default value Of course the prose can always call for throwing if a member is not set. -Boris
[WEBIDL] nullable dictionary members
Hi Cameron, I have a question about the use of *nullable* type for dictionary definition. Having said that dictionary members are inherently optional by definition, is it meaningful (and valid) to mark optional fields as nullable? For example, dicationary Foo { DOMString iWantToBeRequired = Default; DOMString? iWantToBeNullable; DOMString iAmAlreadyOptional; }; Do the two dictionary members iWantToBeNullable and iAmAlreadyOptional semantically make any difference? I was thinking spec writers sometimes encounter situations where they would like to explicitly describe certain dictionary members are required while others are not. Regards, Jungkee Jungkee Song Samsung Electronics
[WEBIDL] nullable dictionary
Hi Cameron, While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? Regards, Jungkee Jungkee Song Samsung Electronics
Re: [WEBIDL] nullable dictionary
Hi Jungkee, Jungkee Song: While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? That's right. I've corrected that description of allowable dictionary member types, as well as for operation return types and arguments. Thanks, Cameron