W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Reconciling handling of optional arguments and handling of default values across ES and webidl

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 09 May 2013 09:45:32 -0400
Message-ID: <518BA87C.5040406@mit.edu>
To: Andreas Rossberg <rossberg@google.com>
CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 5/9/13 8:14 AM, Andreas Rossberg wrote:
> On 9 May 2013 03:18, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> I guess let's take this requirement for ES as a sunk compatibility cost.
>> Where do we go with WebIDL?
> Maybe I misunderstand, but is there any reason why WebIDL needs to
> care about the arguments object at all?

Well, WebIDL needs to care about APIs people want to create.  So say 
someone wants to define a function doSomething which coerces its first 
argument to a string, and for the second argument wants to tell apart 
whether it was not passed at all or passed as undefined.  In JS, you 
would do this like so:

   function doSomething(arg1, arg2) {
     arg1 = String(arg2);
     if (arguments.length > 1) {
       // arg2 passed
       if (arg2 === undefined) {
         // explicit undefined
       } else {
         // some value
     } else {
       // arg2 not passed at all

If we want WebIDL to allow such APIS, then webidl either needs a type 
that can express both undefined and "not passed" as separate concepts or 
it needs to pass along the argument count to the underlying prose or 

Right now WebIDL can express something like "not passed or coerced to 
string" (which looks like "optional DOMString"), and it can express "not 
passed or just any value" (which is "optional any"), but can't express 
"not passed, or explicit undefined, or coerced to string".  One question 
is whether it ever needs to do that or whether we can assume that any 
cases that want to treat "not passed" and "undefined" differently would 
always want the 'any' type anyway.

Received on Thursday, 9 May 2013 13:46:03 UTC

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