- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 11 Oct 2012 20:51:45 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- 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 10/11/12 8:43 PM, Jonas Sicking wrote: > 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. It's the second one as written. If the int arg there were [TreatUndefinedAs=Missing], then the first overload would be chosen, as WebIDL is written today. And if we made undefined default to missing, it would presumably be the first one in this example. Which is why I asked what happens when you have a second, non-undefined arg after that... I agree that these are edge cases, of course; as long as we end up with something that's sort of sane I'm not too worried about exactly what it is. > 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. I'm not that sanguine about it so far, but maybe that's because most spec authors so far don't really understand WebIDL very well... >> 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. I can live with that. -Boris
Received on Friday, 12 October 2012 00:52:19 UTC