-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: list_ods_sheets
vs ods_sheets
#133
Comments
I suspect that we will have the same issues with While I agree that it might actually be better to keep I would vote for the unfortunate compromise of keeping both and removing the warning from |
A crazy idea is to invite the |
readxl is in a very quiescent phase right now. So, between that and general lack of a compelling reason to fiddle with it, I think it's unlikely you'll see such a change in readxl. |
Following up #131, I think it is better to leave this for the community to decide. The interim solution so far is to keep
ods_sheets
at least until v3. But what should we do for v3?list_ods_sheets
conforms to the so-called Tidy Design Principles on function names. It's a verb. All other functions (although not many) in this packages are verbs:read_ods
andwrite_ods
.However,
readxl::excel_sheets
violates the Tidy Design Principles, even thoughreadxl
is part of Tidyverse. IfreadODS
emulatesreadxl
, we should keepods_sheets
. An additional argument is reverse dependencies: several packages useods_sheets
.Looking beyond
readxl
,DBI
usesdbListTables
. There are also base functions such aslist.files
,list.dirs
.The text was updated successfully, but these errors were encountered: