- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Thu, 9 May 2013 14:06:57 -0700
- 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 typechecking. drawImage specifies its overload sets (3, 5, 9). Why can't webIdl overload can match the algorithm for that without checking argument types? -- Garrett Twitter: @xkit personx.tumblr.com
Received on Thursday, 9 May 2013 21:07:25 UTC