W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

RE: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Fri, 10 Dec 2010 23:50:31 +0000
To: Jeremy Orlow <jorlow@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E0623D8263@TK5EX14MBXC124.redmond.corp.microsoft.com>

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow
Sent: Friday, December 10, 2010 7:27 AM
>> 
>> In addition to createObjectStore, I also intend to convert the following over:
>>
>>
>> IDBObjectStore.createIndex
>> IDBObjectStore.openCursor
>> IDBIndex.openCursor
>> IDBIndex.openKeyCursor
>> IDBKeyRange.bound

Sounds great.

>> We did all of these two weeks ago in Chromium and have gotten some feedback.  The main downside is that typos are silently ignored by JavaScript.  We considered throwing if someone passed in an option we didn't recognize, but this would make it impossible to add more options later (which is one of the main reasons for doing this change).  I think what we might do is just log something in the console with this happens.  (Should the spec actually make a recommendation to this effect?)  Besides that, I think overall we're happy with the change.

I'm not sure what the problem is with throwing. Can't each implementation throw if it receives a parameter that has no meaning for it? Given that we can't know if future options will have substantial impact on the behavior of the function when they are present, it looks safer to go that route.

Is there prior art in some other webapps API that takes JavaScript objects as parameters? What do they do?

Thanks
-pablo
 
Received on Friday, 10 December 2010 23:51:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT