That sounds great to me. On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu <andr...@google.com> wrote:
> On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu <andr...@google.com> > wrote: > > On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro > > <pablo.cas...@microsoft.com> wrote: > >> > >> 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. > > > > This is fine with me. > > > >> The only thing I'm not sure is if there is precedent of doing this in > one of the standard APIs. > >> > > > > There is: http://dev.w3.org/geo/api/spec-source.html#position_interface > > > > Sorry, I meant PositionOptions: > > http://dev.w3.org/geo/api/spec-source.html#position-options > > Andrei >
