W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: IndexedDB: undefined parameters

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 10 Oct 2012 22:03:48 -0400
Message-ID: <50762904.1000103@mit.edu>
To: Brendan Eich <brendan@mozilla.org>
CC: Jonas Sicking <jonas@sicking.cc>, Robert Ginda <rginda@chromium.org>, Alec Flett <alecflett@chromium.org>, public-webapps@w3.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 10/10/12 9:55 PM, Brendan Eich wrote:
> undefined is the one value that acts as the default-triggering sentinel,


>> Think about all this from the point of view of an ES impl of foo()
>> above.  How would you represent, in an ES function that expects its
>> first argument to be an int and the second argument to be an int but
>> makes them optional, the concept of "second int passed, but first not
>> passed"?  However you'd do that, that's probably what WebIDL should
>> aim for.
> undefined as first actual, int as second.

OK, so it sounds like there are two proposals for changes to WebIDL here:

1)  If undefined is passed for an optional value that has a default 
value, the default value should be used.

2)  If undefined is passed for an optional value that does NOT have a 
default value, the value should be considered as "not present" (similar 
to the equivalent concept for dictionaries).

Should "undefined", when provided for a dictionary entry, also be 
treated as "not present"?  That is, should passing a dictionary like so:

   { a: undefined }

be equivalent to passing a dictionary that does not contain "a" at all?

How should #2 above interact with the overload resolution algorithm?  Or 
does it not affect it at all?

Received on Thursday, 11 October 2012 02:04:19 UTC

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