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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 27 Sep 2013 01:40:16 -0400
Message-ID: <52451A40.8090601@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Cameron McCormack <cam@mcc.id.au>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Brendan Eich <brendan@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 9/27/13 1:25 AM, Domenic Denicola wrote:
> This does not match ES6, where it would be zero if you wrote
> function foo(arg1 = undefined, arg2) {

That's true.  But why would you write that?

Allen and I spent a while talking about this last week, with not much 

The current ES6 .length rules are basically designed around the fact 
that ES6 doesn't have a good concept of "how many arguments does this 
function expect?" so it has to guesstimate that based on the parameter list.

But in WebIDL we are actually giving more information about how many 
arguments the function expects.

So given this WebIDL:

   void foo(optional long arg1, long arg2);

I would claim that the right ES expression for it (that would match the 
actual WebIDL semantics) would be:

   function foo(arg1, arg2) {
     if (arguments.length < 2) throw new TypeError("Need 2 args");
     if (arg1 !== undefined) {
       arg1 = arg1 >> 0;
     arg2 = arg2 >> 0;

or so.

A bigger problem is this WebIDL:

   void foo(optional long arg1 = 5, long arg2);

How to map that to ES is interesting: you could use a default value on 
the formal parameter, or you could just check in the function body.... 
and the .length would be different depending on how you did it.

You could make a case that we should shoehorn this stuff into the 
limitations of ES formal parameter lists somehow, but I believe the 
spirit of .length, that it be the number of arguments the function 
typically expects, is better served by the definition Cameron has in the 
spec right now.

> I suppose you could not map "optional" to "= undefined"

Indeed.  It's not = undefined at all.

> but that seems most natural


> and fits well with how I assume default arguments in WebIDL should be mapped to ES.


In some ways this whole discussion about .length is pointless, since in 
practice no one really cares about what .length is on functions, I 
suspect....  But if we're going to have this feature (.length on 
functions that's supposed to mean something) I think we should in fact 
have it mean something.

Received on Friday, 27 September 2013 05:40:47 UTC

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