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

Re: IndexedDB: undefined parameters

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 12 Oct 2012 00:29:39 -0700
Message-ID: <CA+c2ei9G--j+B35YsVp4UNaRcwW0rDEDfiG0fz21Gd88ZPNsLw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Brendan Eich <brendan@mozilla.org>, public-webapps@w3.org, Alec Flett <alecflett@chromium.org>, Robert Ginda <rginda@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>
On Oct 11, 2012 5:51 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
> 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.

I think that whatever we choose to do here, patterns like the ones in your
or my example aren't going to be obvious to web authors.

Which is why I think we should discourage them in prose or in rules in

>> 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...

I somewhat agree, but I don't think that anything we do here is going to
have a big effect on what spec authors do.

>>> If so, all we're really saying is that overload resolution will drop
>>> _trailing_ undefined from the argc before determining the overload to
>>> right?
>> If we go with option B above, then doing that sounds good yes.
> I can live with that.

For what it's worth, I'm fine with either function getting selected from
your original example.

/ Jonas
Received on Friday, 12 October 2012 07:30:07 UTC

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