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

Re: IndexedDB: undefined parameters

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 11 Oct 2012 20:51:45 -0400
Message-ID: <507769A1.3030908@mit.edu>
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:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:07 UTC