- 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:19 UTC