On Tue, 09 Oct 2012 19:52:27 +0200, Joshua Bell <[email protected]>
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
