[fsp] Group arguments for API methods and events in dictionaries.

[fsp] Group arguments for API methods and events in dictionaries.

By moving the options to a list, we can add more fields in the future without
breaking backward compatibility.

This CL is the first part of the cleanup. Arguments for callbacks will be
refactored separately.

TEST=unit_tests, browser_tests: *FileSystemProvider*
BUG=373165
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276367

[mtomasz, 2014-06-10 04:14:43]

@benwells: PTAL at IDL,
@kinaba: PTAL at the rest.

Note, that field names are now hard coded. Currently, we do not generate
dictionary field names from IDL. I'm tracking this issue here: crbug.com/382788.

I can add temporarily constants for key names in operations/*.h if you prefer.

[kinaba, 2014-06-10 07:38:09]

lgtm for the code.

Defer the judgement to benwells@ if the idea itself is ok (I think it is.)

https://codereview.chromium.org/329483002/diff/1/chrome/test/data/extensions/...
File chrome/test/data/extensions/api_test/file_system_provider/big_file/test.js
(right):

https://codereview.chromium.org/329483002/diff/1/chrome/test/data/extensions/...
chrome/test/data/extensions/api_test/file_system_provider/big_file/test.js:167:
console.error('*****');
:)

[benwells, 2014-06-10 07:53:11]

+kalman whose API design sensibilities are better than mine.

I'm still pondering my response. My initial reaction is not great, but it's late
and I need to think about exactly why this makes me uneasy. Maybe I'm just old
fashioned :)

[mtomasz, 2014-06-10 07:56:02]

On 2014/06/10 07:53:11, benwells wrote:
> +kalman whose API design sensibilities are better than mine.
> 
> I'm still pondering my response. My initial reaction is not great, but it's
late
> and I need to think about exactly why this makes me uneasy. Maybe I'm just old
> fashioned :)

@benwells: What makes you uneasy? (1) Grouping arguments to dictionaries, (2)
hard-coding key values or (3) crbug.com/382788?

[benwells, 2014-06-10 08:20:26]

On 2014/06/10 07:56:02, mtomasz wrote:
> On 2014/06/10 07:53:11, benwells wrote:
> > +kalman whose API design sensibilities are better than mine.
> > 
> > I'm still pondering my response. My initial reaction is not great, but it's
> late
> > and I need to think about exactly why this makes me uneasy. Maybe I'm just
old
> > fashioned :)
> 
> @benwells: What makes you uneasy? (1) Grouping arguments to dictionaries, (2)
> hard-coding key values or (3) crbug.com/382788?

(1) having arguments for all functions grouped into dictionaries.

Off the cuff reasons why I don't really like it:
- it is less readable
- sometimes it is better to make things incompatible
- the app.window api is a horror
- you can have optional parameters which is equivalent, if you need to add
parameters later and they are indeed optional.
- it doesn't feel like javascript anymore
- how do you enforce mandatory arguments
- if this is a good thing all APIs should be like this

But like I said it is getting late and we had a long weekend in Sydney, so my
brain is fragile. Maybe this is a good idea and I'm just being a
stick-in-the-mud fuddy duddy.

I'm interested to hear what kalman@ has to say.

[mtomasz, 2014-06-10 08:26:44]

On 2014/06/10 08:20:26, benwells wrote:
> On 2014/06/10 07:56:02, mtomasz wrote:
> > On 2014/06/10 07:53:11, benwells wrote:
> > > +kalman whose API design sensibilities are better than mine.
> > > 
> > > I'm still pondering my response. My initial reaction is not great, but
it's
> > late
> > > and I need to think about exactly why this makes me uneasy. Maybe I'm just
> old
> > > fashioned :)
> > 
> > @benwells: What makes you uneasy? (1) Grouping arguments to dictionaries,
(2)
> > hard-coding key values or (3) crbug.com/382788?
> 
> (1) having arguments for all functions grouped into dictionaries.
> 
> Off the cuff reasons why I don't really like it:
> - it is less readable
> - sometimes it is better to make things incompatible
> - the app.window api is a horror
> - you can have optional parameters which is equivalent, if you need to add
> parameters later and they are indeed optional.
> - it doesn't feel like javascript anymore
> - how do you enforce mandatory arguments
> - if this is a good thing all APIs should be like this
> 
> But like I said it is getting late and we had a long weekend in Sydney, so my
> brain is fragile. Maybe this is a good idea and I'm just being a
> stick-in-the-mud fuddy duddy.
> 
> I'm interested to hear what kalman@ has to say.

Got it. This solution was actually suggested by @kalman during the API review.
https://docs.google.com/document/d/1fKtlEEJFIah1WIgUgEnYhZD6dHNhGfpVr39LWdEX9...

[not at google - send to devlin, 2014-06-10 18:31:30]

yep, long argument lists == bad, so for consistency make all argument lists
objects. I just skimmed the idl and that lgtm.

[mtomasz, 2014-06-11 00:51:57]

https://codereview.chromium.org/329483002/diff/1/chrome/test/data/extensions/...
File chrome/test/data/extensions/api_test/file_system_provider/big_file/test.js
(right):

https://codereview.chromium.org/329483002/diff/1/chrome/test/data/extensions/...
chrome/test/data/extensions/api_test/file_system_provider/big_file/test.js:167:
console.error('*****');
On 2014/06/10 07:38:09, kinaba wrote:
> :)

Oops! Done.

[benwells, 2014-06-11 00:52:35]

ok, lgtm then :)

[mtomasz, 2014-06-11 01:26:40]

On 2014/06/11 00:52:35, benwells wrote:
> ok, lgtm then :)

yay!

[mtomasz, 2014-06-11 01:26:44]

The CQ bit was checked by mtomasz@chromium.org

[commit-bot: I haz the power, 2014-06-11 01:28:14]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mtomasz@chromium.org/329483002/20001

[commit-bot: I haz the power, 2014-06-11 12:28:29]

Change committed as 276367