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

Re: an idea for replacing arguments.length

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 11 Nov 2013 10:37:18 -0800
Cc: es-discuss@mozilla.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-Id: <1C11F4D1-BCE3-4136-BA2C-0E389206D9EF@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On Nov 10, 2013, at 6:12 PM, Boris Zbarsky wrote:

> ...
> I believe even for all of these, we could treat them as overloads on the "type" of some argument, where we allow "undefined" as a type that matches the argument not being present or an argument being optional.
> So a viable way forward in terms of WebIDL overloads, perhaps, is to simply disallow overloading on both argument count and argument types (modulo the proviso about undefined above, somehow) and require that overloads for a name either all have an argument that can be used to distinguish them from each other or take different argument counts but not both.  Or something.
> This does nothing for getting rid of the need to check arguments.length in overloads that overload on the arg count, of course.  We could be more radical and recast it all in terms of examining types, treating missing arguments as undefined but that would break compat in at least canvas methods, unfortunately, and I don't think we _really_ want to go there.
> On the other hand, what we probably _could_ do if we make the split above is make overloading on arg count explicitly deprecated (e.g. enforce in UAs that no new APIs that use it get added).

My, perhaps more radical, recommendation would be to only do overloading based upon argument counts and to treat all type overloads for a given argument length as union types that are left to a function's implementation to discriminate.  That would vastly simplify the WebIDL overload dispatch and pretty much eliminate the idea that WebIDL based methods must be exotic objects with distinctive [[Call]] behavior.

Also, I would outlaw (new) overloads like

 TouchList createTouchList(Touch... touches);
 TouchList createTouchList(sequence<Touch> touches);

In the general case in JS code it can be quite problematic to distinguish these and hence this pattern really should be used.  There is much regret about the main place this pattern occurs in the ES built-ins:
    var a = new Array(1,2,3);  //create a three element array with with elements initialized to 1,2,3
    var b = new Array(1); //create a sparse array whose length is set to 1;

Received on Monday, 11 November 2013 18:37:49 UTC

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