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

On Tue, Dec 14, 2010 at 12:13 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>
> On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>>>
>>> Btw, I forgot to mention IDBDatabase.transaction which I definitely think should take an options object as well.
>>
>> Hmm.. I think we should make the first argument required, I actually thought it was until I looked just now. I don't see what the use case is for opening all tables.
>
> FWIW I'm finding that the majority of the IndexedDB code I read and write does indeed need to lock everything.  I'm also finding that most of the code I'm writing/reading won't be helped at all by defaulting to READ_ONLY...
>
>>
>> In fact, it seems rather harmful that the syntax which will result in more lock contention is simpler than the syntax which is better optimized.
>
> But you're right about this.  So, if we're trying to force users to write highly parallelizable code, then yes the first arg probably should be required.  But if we're trying to make IndexedDB easy to use then actually the mode should probably be changed back to defaulting to READ_WRITE.
> I know I argued for the mode default change earlier, but I'm having second thoughts.  We've spent so much effort making the rest of the API easy to use that having points of abrasion like this seem a bit wrong.  Especially if (at least in my experience) the abrasion is only going to help a limited number of cases--and probably ones where the developers will pay attention to this without us being heavy-handed.

I think "ease of use" is different from "few characters typed". For
example it's important that the API discourages bugs, for example by
making the code easy and clear to read. Included in that is IMHO to
make it easy to make the code fast.

>> This leaves two optional arguments, the second of which is likely very rarely going to be used. In fact, I wouldn't mind removing it entirely since it just seems like it risks causing race conditions. And it's technically syntax sugar since you can always use setTimeout and call .abort() manually.

For what it's worth, apparently jQuery has had as a general rule of
thumb to use options objects whenever functions have *more than 3*
optional arguments.

Personally this sounds high to me, especially since it's forced them
to do some crazy tricks a few times where functions have grown
additional optional arguments over time. But it's an interesting
data-point nonetheless.

/ Jonas

Received on Monday, 10 January 2011 21:41:42 UTC