- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 11 Oct 2011 13:53:11 -0700
- To: Brendan Eich <brendan@mozilla.org>
- Cc: Erik Arvidsson <arv@chromium.org>, "Mark S. Miller" <erights@google.com>, Dominic Cooney <dominicc@google.com>, public-script-coord@w3.org
On Tue, Oct 11, 2011 at 10:42 AM, Brendan Eich <brendan@mozilla.org> wrote:
> On Oct 11, 2011, at 1:25 PM, Erik Arvidsson wrote:
>
>> Also, worth considering is optional arguments in the current ES6
>> draft. In ES6 the value undefined is not treated as absent.
>>
>> function f(x = 42) {
>> return x;
>> }
>>
>> print(f()); // "42"
>> print(f(undefined)); // "undefined"
>>
>> So, to me it seems like the WebIDL to ES mappings needs to treat
>> undefined as present.
>
> Agreed. Ad-hoc argument processing in JS today may use arguments.length, or undefined testing (possibly even null-or-undefined testing via " == null"). I continue to think arguments.length is the best way for IDL.
This doesn't match the feedback we got in the thread where we decided
on undefined-checking rather than arguments.length.
I don't really have a strong feeling either way as I don't have enough
experience with how JS developers think.
I will note that when we redid how we handle optional arguments for
XMLHttpRequest.open, we did have to add special code to deal [1] with
some common library doing:
xhr.open("GET", url, true, username || undefined, password || undefined);
Our current solution to that problem is to special-case XHR.open such
that it stringifies undefined to "" rather than the normal
"undefined". If we instead made our code do undefined-testing rather
than arguments.length-testing then we'd treat the above as
xhr.open("GET", url, true);
which would give the correct behavior.
That said, I'll leave it to others to decide what the best solution is
to use here and for dictionaries.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=605296
/ Jonas
Received on Tuesday, 11 October 2011 20:54:17 UTC