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

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 UTC