W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Changing the default overwrite behavior of Put

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 17 Jun 2010 10:40:17 -0700
Message-ID: <AANLkTil1dPH7S2eErAHBa-rpMnY5Ul1eyrN6x99Z42Vb@mail.gmail.com>
To: Shawn Wilsher <sdwilsh@mozilla.com>
Cc: Kris Zyp <kris@sitepen.com>, Jeremy Orlow <jorlow@chromium.org>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>
On Thu, Jun 17, 2010 at 10:33 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
> On 6/17/2010 10:26 AM, Kris Zyp wrote:
>>
>> My order of preference:
>> 1. parameter-based:
>> put(record, {id: "some-id", overwrite: false, ... other parameters ..});
>> This leaves room for future parameters without a long positional
>> optional parameter list, which becomes terribly confusing and
>> difficult to read. In Dojo we generally try to avoid more than 2 or 3
>> positional parameters at most before going to named parameters, we
>> also avoid negatives as much as possible as they generally introduce
>> confusion (like noOverwrite).
>> 2. Two methods called "put" and "create" (i.e. put(record, id) or
>> create(record, id))
>> 3. Two methods called "put" and "add".
>
> Agree with either (2) or (3).  I don't like (1) simply because I don't know
> any other web API that uses that form, and I think we shouldn't break the
> mold here.  Libraries certainly can, however.  Might prefer (3) over (2)
> only because add is shorter than create.

I tend to prefer 3 over 2 as well. I would expect a function called
'create' to be some sort of factory function, like createElement,
which obviously isn't the case here.

/ Jonas
Received on Thursday, 17 June 2010 17:41:14 GMT

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