From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Thursday, August 12, 2010 3:59 AM
>> On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow <jor...@chromium.org> wrote: >> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 >> > One quesiton though: if they pass in null or undefined, do we want to >> > interpret this as the argument not being passed in or simply let them >> > convert to "undefined" and "null" (which is the default behavior in WebIDL, >> > I believe). I feel somewhat strongly we should do the former. Especially >> > since the latter would make it impossible to add additional parameters to >> > .open() in the future. >> I don't understand why it would make it impossible to add optional >> parameters in the future. Wouldn't it be a matter of people writing >> >> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM); >> >> vs. >> >> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM); >> >> So "" is assumed to mean "don't update"? My assumption was that "" meant >> empty description. >> >> It seems silly to make someone replace the description with a space (or >> something like that) if they truly want to zero it out. And it seems silly >> to ever make your description be >> "null". So it seemed natural to make >> null and/or undefined be such a signal. Given that open() is one of those functions that are likely to grow in parameters over time, I wonder if we should consider taking an object as the second argument with names/values(e.g. open("mydatabase", { description: "foo" }); ). That would allow us to keep the minimum specification small and easily add more parameters later without resulting un hard to read code that has a bunch of "undefined" in arguments. The only thing I'm not sure is if there is precedent of doing this in one of the standard APIs. Thanks -pablo