Risks of using "function <- package::function" ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Risks of using "function <- package::function" ?

Boris Steipe
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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Risks of using "function <- package::function" ?

Duncan Murdoch-2
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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Risks of using "function <- package::function" ?

Jeff Newmiller
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 <[hidden email]> 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
>
>______________________________________________
>[hidden email] 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.

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Risks of using "function <- package::function" ?

Eric Berger
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 <[hidden email]>
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 <
> [hidden email]> 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
> >
> >______________________________________________
> >[hidden email] 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.
>
> ______________________________________________
> [hidden email] 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.
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: Risks of using "function <- package::function" ?

Duncan Murdoch-2
In reply to this post by Jeff Newmiller
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

______________________________________________
[hidden email] 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.