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

On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

I can't remember getting a single bug filed on Geckos current
behavior. There probably have been some which I've missed, but it's
not a big enough problem that it's ever been discussed at mozilla as
far as I can remember.

> We saw that happen with addEventListener.

The reason we made the last argument optional for addEventListener
wasn't that we had compatibility problems, but rather that it seemed
like a good idea as the argument is almost always set to false, and
being the last argument, making it optional works great.

The fact that webkit already had this behavior was only discussed tangentially.

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

Yes. In fact, unless someone can show that the web depends on the
currently specced behavior, I don't see a reason to change Gecko.

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

I agree, throwing seem better as it's more likely a bug on the callers
part. Or at the very least ambiguous which behavior they want which
means it's better to throw.

/ Jonas

Received on Monday, 13 June 2011 06:20:38 UTC