Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

Mark Pilgrim:
> That is highly unintuitive. What's the point of listing the argument as "not
> optional" if it is, in fact, completely optional?

It’s not optional in that if there were another method of the same name
which doesn’t have that argument, you can distinguish between the two
calls.  For example if you had:

  void f();
  void f(in DOMString s);

then in JS if you called obj.f() it would behave as described for the
first method, and if you called obj.f(undefined) or obj.f("whatever") it
would behave as described for the second method.

If you had

  void f(in optional DOMString);

then prose describing the behaviour of f could distinguish between
obj.f() and obj.f("undefined").

And if you had

  void f();
  void f(in optional DOMString);

then it’d be ambiguous which one you’re calling with obj.f().

It’s also not optional in language bindings where function calls and
declarations are stricter than in JS.

But you are right that it’s confusing if you just have a single method

  void f(in DOMString s);

since clearly you can call obj.f() in JS and it won’t throw a TypeError.

> (For that matter, why list it as non-nullable if null is treated like
> the empty string and the empty string is an acceptable value?)

The “non-nullableness” is really a property of the type, not the
argument, and it means whether null is one of the valid values of the
type or not.  So at the IDL level, the value can’t be null.  If in JS
you pass in null, the default coercion behaviour is to turn that into
"".  For arguments of type DOMString, you can pass in pretty much any
kind of value in JS and it’ll get stringified in some way.

Jonas Sicking:
> Huh?? At least in the Gecko DOM implementation we always throw an
> exception if too few parameters are defined. Only if parameters
> are explicitly marked as [optional] are you allowed to not include
> them. I was under the impression that this was the case in most DOM
> implementations, with notable exception of webkit.

WebKit and Chrome, I think, which have independent JS binding code.

Adam Barth:
> > WebKit is looser in this regard.  We probably should change the
> > default for new IDL, but it's a delicate task and I've been busy.  :(

What about for old IDL?  Do you feel that you can make this change
without breaking sites?  One of the “advantages” of specifying the
looser approach is that it’s further down the “race to the bottom” hill,
so if we are going to tend towards it eventually we may as well jump
there now.  We saw that happen with addEventListener.

Jonas Sicking:
> This is why it surprises me of WebIDL specifies WebKit behavior as the
> compliant behavior as Cameron seems to indicate.

In the spec right now it’s listed as an open issue, and it was the
WebKit behaviour that I was going to specify to resolve the issue this
week.  (So it’s not what the spec currently says.)  This is what I
mentioned in
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0094.html
although I didn’t get any pushback then.  I am happy to keep discussing
it but I would like to settle on a solution soon.

So I guess you are arguing for “throw if too few arguments are passed,
ignore any extra arguments”.  When we have overloads like

  void f(in long x);
  void f(in long x, in long y, in long z);

we’d need to decide whether f(1, 2) throws or is considered a call to
the first f with an extra, ignored argument.  The former seems more
consistent to me.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 13 June 2011 03:36:18 UTC