Large packages sometimes mask each other's functions and that creates a headache, especially for teaching code, since function signatures may depend on which order packages were loaded in. One of my students proposed using the idiom <function> <- <package>::<function> ... in a preamble, when we use just a small subset of functions from a larger package. I like that idea and can't see obvious disadvantages(1). Are there subtle risks to that approach? Thanks! Boris (1) I think there could be an issue when packages that are loaded later depend on and extend a function that has has been made local. But I'm not even sure what happens then, and it may be more of a hypothetical anyway - can't even think of a situation with which to test it off the top of my head.
Risks of using "function <- package::function" ?
5 messages · Boris Steipe, Jeff Newmiller, Eric Berger +1 more
On 16/11/2017 4:53 PM, Boris Steipe wrote:
Large packages sometimes mask each other's functions and that creates a headache, especially for teaching code, since function signatures may depend on which order packages were loaded in. One of my students proposed using the idiom <function> <- <package>::<function> ... in a preamble, when we use just a small subset of functions from a larger package. I like that idea and can't see obvious disadvantages(1). Are there subtle risks to that approach?
You might do it twice. R isn't going to complain if you have filter <- stats::filter # some other code here... filter <- dplyr::filter in your code, but the second one will overwrite the first one. The normal way to handle this is in the NAMESPACE file, where you should have importFrom(stats, filter) If you then have importFrom(dplyr, filter) you should get an warning: Warning: replacing previous import ?stats::filter? by ?dplyr::filter? when loading ?testpkg?. Duncan Murdoch
Obvious? How about "obscurity"? Just directly use pkg::fun if you have name collision.
Sent from my phone. Please excuse my brevity. On November 16, 2017 4:46:15 PM PST, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >On 16/11/2017 4:53 PM, Boris Steipe wrote: >> Large packages sometimes mask each other's functions and that creates >a headache, especially for teaching code, since function signatures may >depend on which order packages were loaded in. One of my students >proposed using the idiom >> >> <function> <- <package>::<function> >> >> ... in a preamble, when we use just a small subset of functions from >a larger package. I like that idea and can't see obvious >disadvantages(1). >> >> Are there subtle risks to that approach? > >You might do it twice. R isn't going to complain if you have > >filter <- stats::filter > ># some other code here... > >filter <- dplyr::filter > >in your code, but the second one will overwrite the first one. > >The normal way to handle this is in the NAMESPACE file, where you >should >have > >importFrom(stats, filter) > >If you then have > >importFrom(dplyr, filter) > >you should get an warning: > >Warning: replacing previous import ?stats::filter? by ?dplyr::filter? >when loading ?testpkg?. > >Duncan Murdoch > >______________________________________________ >R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide >http://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code.
As Jeff recommends, I use the pkg::fun for clarity. However I probably use it more than needed (e.g. I use the dplyr:: prefix on all dplyr function calls instead of just the functions with name collisions). Are there any tools that can be used (like a form of lint) to identify uses of functions without the pkg:: prefix and which are part of a name collision? One could then edit the code to include the pkg:: prefix to disambiguate those cases and verify via a repeated use of such a tool that there are no outstanding cases. Or alternative approaches to the issue? Thanks, Eric On Fri, Nov 17, 2017 at 9:30 AM, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote:
Obvious? How about "obscurity"? Just directly use pkg::fun if you have name collision. -- Sent from my phone. Please excuse my brevity. On November 16, 2017 4:46:15 PM PST, Duncan Murdoch < murdoch.duncan at gmail.com> wrote:
On 16/11/2017 4:53 PM, Boris Steipe wrote:
Large packages sometimes mask each other's functions and that creates
a headache, especially for teaching code, since function signatures may depend on which order packages were loaded in. One of my students proposed using the idiom
<function> <- <package>::<function> ... in a preamble, when we use just a small subset of functions from
a larger package. I like that idea and can't see obvious disadvantages(1).
Are there subtle risks to that approach?
You might do it twice. R isn't going to complain if you have filter <- stats::filter # some other code here... filter <- dplyr::filter in your code, but the second one will overwrite the first one. The normal way to handle this is in the NAMESPACE file, where you should have importFrom(stats, filter) If you then have importFrom(dplyr, filter) you should get an warning: Warning: replacing previous import ?stats::filter? by ?dplyr::filter? when loading ?testpkg?. Duncan Murdoch
______________________________________________ R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
______________________________________________ R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/ posting-guide.html and provide commented, minimal, self-contained, reproducible code.
On 17/11/2017 2:30 AM, Jeff Newmiller wrote:
Obvious? How about "obscurity"? Just directly use pkg::fun if you have name collision.
One disadvantage of this is that the availability of pkg may not be checked until you use it. Package checks will complain if you haven't declared in the DESCRIPTION file that you are importing from pkg, but the package will run even if you ignore that check. But one thing I just realized is that Boris was probably not talking about writing a package, he was likely thinking about writing scripts. Then DESCRIPTION and NAMESPACE files don't exist, and his student's suggestion seems like a reasonable idea, more in the spirit of named imports than using "library(pkg)" or "require(pkg)". Duncan Murdoch