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: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 9 May 2013 14:06:57 -0700
Message-ID: <CABZUbM1AGA3P+a3bU1aHp5OEhy4f4fJZYLQv=iYQ-SLVT9uQQA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Andreas Rossberg <rossberg@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 5/9/13, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/9/13 3:09 PM, Garrett Smith wrote:
>> Too much complexity from overloading and too many parameters. A value
>> object would be a consideration for API redesign.
> This API can't be "redesigned".  We all agree it's a crappy API, but
> it's widely used.  The question is to what extent we can/should change
> its behavior in edge cases without a wholesale redesign.
I acknowledge the circumstance.

Although it is off-topic here, I disagree that the API cannot be
redesigned. One or more new methods and/or objects can be created if
those involved agree that doing so is worthwhile.

>>>     drawImage(image, 0, 0, undefined);
>>> should do.  In today's world it throws.  Should WebIDL preserve the
>>> ability to do that in that situation?
>> According to the spec, it looks like that isn't valid but I don't see
>> what it says about what happens when four arguments are passed.
> See
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm
> which will end up throwing in step 7.
Wow that is a long, complicated algorithm. WebIDL overload algorithm
doesn't just cover matching argument list lengths, it also takes on

drawImage specifies its overload sets (3, 5, 9). Why can't webIdl
overload can match the algorithm for that without checking argument
Twitter: @xkit
Received on Thursday, 9 May 2013 21:07:25 UTC

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