@adam3smith, @kuriwaki, @pdurbin, and anyone else,

Should get_file() be refactored into multiple child functions? It seems like we're asking it to do a lot of things, including

• retrieve by file id or by file name
• retrieve single file or multiple files
• in #35, @kuriwaki has the cool suggestion of returning a specific file format (like Stata)
• in #35, I hijacked @kuriwaki's thread to suggest also returning R's native data.frame or tibble.
• in PR #47, @adam3smith has a cool solution of downloading multiple files as a single zip (also discussed in #46)

I like all these capabilities, and want to run discuss organizational ideas with people so the package structure is (a) easy for us to develop, test, & maintain, and (b) useful and natural to users to learn and incorporate.

One possible approach:
A foundational functional retrieves the file(s) by ID; it is the workhorse that actually retrieves the file. A second function accepts the file name (not ID); it essentially wraps the first function after calling get_fileid(). Both of these functions deal with a single file at a time.

Another pair of functions deal with multiple files (one by name, one by id). But these return lists, not a single object. They're essentially lapplys/loops around their respective siblings described above.

To avoid breaking the package interface, maybe the existing get_file() keeps its same interface (that ambiguously accepts with file names or id and returns either single files or a list of files), but we soft-deprecate it and encourage new code to use these more explicit functions? The guts of the function is moved out into the four new functions

Maybe the function names are

1. the existing get_file() with an unchanged interface
2. get_file_by_id() (the workhorse)
3. get_file_by_name()
4. get_files_by_id()
5. get_files_by_name()
6. get_tibble_by_id()
7. get_tibble_by_name()
8. get_zip_by_id()
9. get_zip_by_name()

I'm pretty sure it would be easier to write tests that isolate problems. The documentation becomes more verbose, but probably more straight-forward.

You guys have more experience with Dataverse than I do, and better sense of the use cases. Would this reorganization help users? If not, maybe we still split it into multiple functions, but just keep the visibility of functions 2-5 private.

Maybe I'm making this unnecessarily tedious, but I'm thinking that these download functions are the most called by R users, and they're certainly the ones that are called by new users. So if they leave a bad impression, the package is less likely to be used.