W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

Representing a "dictionary or not present" member in a dictionary return value

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 04 Mar 2014 21:20:23 -0500
Message-ID: <531689E7.8050706@mit.edu>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
Consider this (current invalid) WebIDL:

   dictionary A {};
   dictionary B {};
   dictionary C {
     A a;
     B? b;
   interface I {
     C getSomething();

This is invalid because a nullable dictionary type cannot be the member 
of another dictionary.  And if that member were removed, then the return 
value of getSomething would be an object which would always have a 
property named "a" whose value would be another object (possibly with no 
properties).  That is, there is no real way to represent a "missing" 
state for a dictionary that's a member of another dictionary.

Those restrictions are there because for dictionaries used as arguments 
we want to treat "missing", null, and an object with no properties as 
all being the same thing.  But for return values it makes sense to 
differentiate between some of these cases.  For one thing, dictionary 
return values, unlike arguments, typically don't represent some sort of 
options object, but something more akin to a struct of some sort.

Do we want to support a way to do such differentiation?  If so, how do 
we want to do it?

Option 1 is to allow dictionary members in dictionary return values to 
be missing (and hence not lead to the creation of a corresponding 
property on the object).

Option 2 is to allow nullable dictionaries as members of dictionary 
return values (just like we currently allow them as return values 
directly).  In the case above, using C as an argument would do the 
conversion for the "b" member the same way as if it were not marked 
nullable, but using C as a return value would allow either an object or 
null to be used as the value of "b".

Or I guess we could support both, if there are use cases for it.


Received on Wednesday, 5 March 2014 02:20:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC