W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 13 Jun 2011 00:15:31 -0700
Message-ID: <BANLkTi=o3LU0+YCGNjGQ6rAA4Z=+tOD+0Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Mark Pilgrim <pilgrim@google.com>, Eliot Graff <Eliot.Graff@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Israel Hilerio <israelh@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>
On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Unfortunately, there's a bunch of WebKit-dominate content out there
that folks are afraid to break.  We discussed this topic on some bug
(which I might be able to dig up).  The consensus was that the value
in tightening this for old APIs wasn't worth the compat risk (e.g., in
mobile and in Mac applications such as Dashboard and Mail.app).

For new APIs, of course, we can do the tighter things (which I agree
is more aesthetic).  It mostly requires someone to go into the code
generator and make it the default (and then to special-case all the
existing APIs).  I'd like to do that, but it's a big job that needs to
be done carefully and I've got other higher priority things to do, so
it hasn't happened yet.


>> 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 07:16:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC