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.
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.
Maybe Matching Threads
- Risks of using "function <- package::function" ?
- Risks of using "function <- package::function" ?
- roxygen2 / documentation of reexports
- infinite recursion during package installation with methods, setAs
- possible bug R CMD check: No space(s) allowed after \VignetteDepends{}