- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Oct 2012 22:52:00 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Brendan Eich <brendan@mozilla.org>, 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 Wed, Oct 10, 2012 at 7:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.
I think we should do this in order to align with ES6.
> 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).
I think we should do this in order to align with what I'd say is the
spirit of ES6.
The reason for making 'undefined' get the default value is that it
makes expressions like:
foo(obj.prop);
not have to be written as:
if ("prop" in obj) {
foo(obj.prop);
}
else {
foo();
}
In order to keep with that goal we should for these purposes also
treat undefined as "not passed".
/ Jonas
Received on Thursday, 11 October 2012 05:52:56 UTC