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: Thu, 11 Oct 2012 17:43:17 -0700
Message-ID: <CA+c2ei-go4Qp9pyzzsV+UDXun=bfScW1uphmzXkvhnc5Ge+vnQ@mail.gmail.com>
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.


> 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


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

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