- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 11 Oct 2012 17:43:17 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Brendan Eich <brendan@mozilla.org>, Robert Ginda <rginda@chromium.org>, Alec Flett <alecflett@chromium.org>, public-webapps@w3.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, Oct 11, 2012 at 12:15 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/11/12 3:06 PM, Jonas Sicking wrote: >> >> Make the overload resolution treat a passed 'undefined' value the same >> as not passing the argument. > > > That's not sufficient to just say; we need to define how that will actually > work. Yes, definitely. I didn't intend for my email to be a full spec. I'm sure there are lots of edgecases to define. > The important difference being that not passing an argument is only possible > at the end of the arglist, but undefined can appear in the middle. Indeed. > As an example, what happens in this situation: > > void foo(optional int x, optional int y); > void foo(MyInterface? x, optional int y); > > and JS like so: > > foo(undefined, 5); In general, I think there's only bad solutions with an interface like the one described above. Even for an API like: void bar(optional int x); void bar(MyInterface? x); with or without the "treat undefined as not-passed" rule, it's definitely not obvious which one bar(undefined); would call. I think the WebIDL spec unambiguously makes it match the second one, but I wouldn't call that obvious to authors. I'd say we can treat this situation in two ways: A) Make such an API a WebIDL error. I.e. not allow two APIs differ only by that one takes 'undefined' and one takes 'null'. B) Rely on that spec authors don't create APIs like this, or if they do, make the two bar functions behave the same for this set of values. In general, WebIDL is ultimately a spec aimed at spec authors, not at developers. We have to make spec authors assume some level of responsibility for the APIs that they create. WebIDL shouldn't be a tool to force people to create great APIs, it should be a tool to enable it. > Per the current overload resolution algorithm, this will invoke the second > overload with a null MyInterface pointer. Is that the behavior we want? > > If so, all we're really saying is that overload resolution will drop > _trailing_ undefined from the argc before determining the overload to use, > right? If we go with option B above, then doing that sounds good yes. / Jonas
Received on Friday, 12 October 2012 00:44:15 UTC