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

Hash: SHA1

On 6/17/2010 10:24 AM, Jeremy Orlow wrote:
> On Wed, Jun 16, 2010 at 9:58 AM, Shawn Wilsher <
> <>> wrote:
>         So, in summary, I agree to splitting the put method in to
>         two - put and putNoOverwrite. I am also in favor of
>         retaining the name as put (contrasted with get). I would
>         like to avoid bikeshedding on names even though there have
>         been ample opportunities on this list lately with that.
>     I think you are completely ignoring the arguments in this thread
>     about the issues with naming it put.  I don't think it is
>     bikeshedding; these seem like legitimate concerns.
> Agreed.  We need to at least discuss whether aligning with REST is
> important.  I don't care much either way, but you should at least
> give Kris a chance to respond.
> Also, if there are only 2 states (overwrite and noOverwrite) then a
> parameter to put (rather than 2 functions) might still be the best
> approach.

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".

Is putNoOverwrite seriously a suggestion? That's sounds like a
terrible name to me.

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

Received on Thursday, 17 June 2010 17:28:24 UTC