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

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

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 5 Mar 2014 22:37:12 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <751f4c8a954a4e69b9e3eac26b465530@BLUPR03MB344.namprd03.prod.outlook.com>
Is there any context for this issue? E.g., has any spec run-up against this problem? (The first one that came to mind--and I don't know if it is impacted by this or not--is the Media Capture and Streams spec with its rather complex "Constraints" dictionaries...

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, March 4, 2014 6:20 PM
To: public-script-coord@w3.org
Subject: Representing a "dictionary or not present" member in a dictionary return value

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 22:38:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:51 UTC