-
-
Notifications
You must be signed in to change notification settings - Fork 45
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
Allow tidyselect-like syntax within use()
#319
Comments
Do you have a more concrete use-case in mind where this would be worthwhile? At the moment I am having a hard time justifying the complexity this would add (both to the code base and to the documentation). In particular, the examples you listed can already be expressed by either importing all desired names explicitly (recommended) or by using the wildcard import Fundamentally, using these functions has all the disadvantages of a wildcard import, because it attaches implicit names. The main issue is that this can silently break user code when a module adds new exports that now override other imports. I’m also comparing with module systems in other languages, and as far as I can see none of them offers an equivalent of what you’re proposing — indicating that this isn’t an important feature. |
I think your arguments against this are solid, so if you decide it's not worth adding, fair enough. I think my main reason for the suggestion is this is that I don't want to have to reuse lengthy Having said that, the more I think about it, the more I think this feature is at odds with the core purpose of {box}. |
This could be seen as an extension of #287.
E.g.
use(purrr[contains("map")])
would importmap()
,imap()
,map_chr()
,map_dbl()
etc. Another common pattern might beuse(ggplot2[ggplot, aes, starts_with("geom_")])
. In my opinion this would do a lot for readability/convenience, and would lend familiarity for those who already use the tidyverse.The only possible issue I can see is that tidyselect would use
everything()
rather than...
to import the whole namespace. I suppose supporting both might be possible, but perhaps not very neat.The text was updated successfully, but these errors were encountered: