Re: an idea for replacing arguments.length

On Mon, Nov 11, 2013 at 2:12 AM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
> One of the the few remaining uses of a function's 'arguments' binding is to
> determine the actual number of passed arguments.  This is necessary in some
> overloading scenarios where a function has different behavior when an
> argument is completely absent then it has when undefined (or any other
> default value) is explicitly passed in that parameter position.  That
> situation occurs in a number of DOM APIs and even a few ES library
> functions.

I think the number is very low. I think I've heard of a total of four
DOM functions which currently treat "not passed" as different from
"explicitly passed undefined". And we're working on changing those so
that the two are treated the same. Unclear if we'll be able to change
all of them.

So from the DOM point of view, I don't see a lot of reason to add
convenience capabilities for detecting that difference.

And in none of the cases in the DOM, does function.length become a
problem. This is because in all of the cases the argument truly is
optional, which means that .length does not include it. So for example
for XMLHttpRequest.open you could write a JS implementation that looks
like:

function open(verb, url, ...args) {
  let [async, username, passwd] = args;
  if (args.length == 0) {
    async = true;
  }
  ... more code here ...
}

It is surprising to me that that is not the case in the ECMAScript
APIs, but seems like that is history.

/ Jonas

Received on Monday, 11 November 2013 06:23:12 UTC