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: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 8 May 2013 18:14:45 -0700
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-Id: <5C0DA3F7-1FE6-461C-B281-5494FA5976A0@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On May 8, 2013, at 5:48 PM, Boris Zbarsky wrote:

> On 5/8/13 7:17 PM, Allen Wirfs-Brock wrote:
>> This is not how argument.length is currently specified in either ES5 or ES6.
> 
> Yes, I'm well aware.
> 
>> That's how JS code distinguishes between missing trailing arguments and explicitly passed undefined.
> 
> Why does it need to distinguish?
> 
> If there are cases when one needs to distinguish, could we please figure out exactly what those are?  I was given to understand that we always wanted to treat undefined the same as "missing argument", in the context of WebIDL, but if that's not the case then please do enlighten me as to the exceptions...
> 
>> some built-ins that are specified to distinguish the missing from undefined arguments cases.
> 
> What are these built-ins and why do they care about the distinction? Understanding that seems important for designing future APIs and for what we do with WebIDL...



There are several built-in library functions in ES that make this distinction.  For example:
   Array(500)   //create an array whose length is 500 with no  own elements.
and
   Array(500, undefined)  //create an array whose length is 2 with own properties 0: 500, 1: undefined

and others. It wouldn't  too hard to make a list.  They typically use words such as "if the foo argument was passed" or "if the foo argument is present".

Probably even more significantly, any one who writes a function can make this distinction using the arguments object and given that the large spec. does it, it's not unreasonable to expect that there is user code that also does it.








> 
> -Boris
> 
Received on Thursday, 9 May 2013 01:15:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC