- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 10 Oct 2012 22:03:48 -0400
- 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? -Boris
Received on Thursday, 11 October 2012 02:04:20 UTC