Consider alternative naming for `cite` and `check` functions

[TimTaylor]

socialmixr masks devtools::check() and utils::cite(). It may be worth considering renaming for user friendliness. Explicit possibilities... check_survey, cite_survey / get_citation() / get_survey_citation().

[sbfnk]

Thanks for raising this. I'm happy to be convinced otherwise but personally I think I prefer function names to be short and qualifications made by specifying the package used, i.e.

devtools::check()
socialmixr::check()

over what would be

check_package() ## from devtools
check_survey() ## from socialmixr

etc. Do you know of any general discussion/guidelines on this? It reminds me of a related discussion we had about function naming in epinowcast.

[TimTaylor]

Fair enough. Re guidance - afraid not.

My main argument would be that for interactive use it is quite common to just call library() when you begin, so making this as frictionless as possible is always preferable (more so for new rather than intermediate R users). My general approach is to avoid (although probably break this often) overwriting base/utils/stats function but not worry about other packages too much.

Re the linked issue and explicit pkg prefix - I've employed that method once or twice but avoid it most of the time as feels over the top for most packages and makes them feel more cumbersome (feels different for both vctrs and stringr / stringi where collisions would be almost unavoidable without).

[Bisaloo]

Beyond the name clash issue, I believe we would gain in clarity by renaming cite() to get_citation() / get_survey_citation() (as suggested by Tim).

Using cite() would be great if it was already a generic in base R but it isn't. (Note that even then, citation() would probably be more appropriate as utils::cite() takes a bibentry and returns a character, while utils::citation() returns a bibentry, like socialmixr::cite.survey().)

Since you're using the newly defined cite() and check() generics on a single class, I believe it's not worth the potential confusion.

If you believe such generics would be widely useful, you can always try to add them in https://github.com/r-lib/generics but I don't know how open they are to external contributions.