-
Notifications
You must be signed in to change notification settings - Fork 14
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
Prefer multiple functions with convenient syntax #82
Conversation
Still needs more documentation work to steer people towards |
I had seen your initial message; I had got so far as to think it could be called The interface is exactly what I had in mind, with the bonus of specifying either |
#Conflicts: # R/disambiguate.R # R/prefer.R
#' conflicts_prefer( | ||
#' dplyr::filter(), | ||
#' dplyr::lag(), | ||
#' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to show the other form in the examples, because i think that is what I'd personally prefer, but it is likely a little confusing to newish R users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also harder to type the form without parens because of autocomplete. But I'll add an example.
#' dplyr::lag(), | ||
#' ) | ||
conflicts_prefer <- function(..., .quiet = FALSE) { | ||
calls <- exprs(...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exprs()
vs enexprs()
? not sure if it matters, we don't capture pure expressions often
is_ok <- vapply(calls, is_ns_call, logical(1)) | ||
if (any(!is_ok)) { | ||
cli::cli_abort( | ||
"All arguments must be in form {.code pkg::fun} or {.fn pkg::fun}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Full stop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops and I need to test it.
@@ -4,16 +4,13 @@ | |||
#' `conflict_prefer()` allows you to declare "winners" of conflicts. | |||
#' You can either declare a specific pairing (i.e. `dplyr::filter()` beats | |||
#' `base::filter()`), or an overall winner (i.e. `dplyr::filter()` beats | |||
#' all comers). | |||
#' all comers). As conflicted 1.2.0, in most case you should use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As _of_ conflicted 1.2.0, in most case_s_ you
#> Either pick the one you want with `::`: | ||
#> • dplyr::filter | ||
#> • stats::filter | ||
#> Or declare a preference with `conflict_prefer()`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you want to mention conflicts_prefer()
here
Fixes #77
@ijlyttle what do you think of this interface? I'm slightly concerned that
conflicts_prefer()
might be confusingly close toconflict_prefer()
.