- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Wed, 10 Oct 2012 20:15:02 +0200
- To: public-webapps@w3.org
On Tue, 09 Oct 2012 19:52:27 +0200, Joshua Bell <jsbell@chromium.org>
wrote:
> We were looking at Opera's w3c-test submissions, and noticed that
> several of them use a pattern like:
>
> request = index.openCursor(undefined, 'prev');
>
> or:
>
> opts = {};
> request = index.openCursor(opts.range, opts.direction);
>
> In Chrome, these throw DataError per our interpretation of the spec: "If
> the range parameter is specified but is not a valid key or a key range,
> this method throws a DOMException of type DataError." [1]
Yes. You are correct.
Some of the first tests I wrote had that pattern, and since the testcases
came before the implementation, the implementation followed the testcases
:P Firefox, which I used to sanity check at the time I wrote them,
allowed it (and still do).
I did check and change a few other tests that I wrote more recently when
checked up against IE10 (and now Chromium), but I didn't go through older
ones.
The tests are meant to follow the spec so they should be fixed. :-)
But I am quite convinced that not having TreatUndefinedAs=Missing is a
painful API design though, for just the reasons others have brought up in
this thread.
I have written one like that for open. In supports.js, there is something
like
# function createdb(name, version) {
# if (!name) name = generate_name()
#
# if (!version) return indexedDB.open(name)
# else return indexedDB.open(name, version)
# }
Where that last if-tests feel very redundant.
Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is meant
to be for legacy API's, and not new ones. I think that a bit strange and
counter productive. Why?
--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Wednesday, 10 October 2012 18:15:33 UTC