RE: [WEBIDL] nullable dictionary members

2012-08-17 Thread Jungkee Song
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

2012-08-16 Thread Boris Zbarsky

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

2012-08-15 Thread Jungkee Song
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

2012-08-08 Thread Jungkee Song
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

2012-08-08 Thread Cameron McCormack

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