Skip to content
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

Importing functions from other packages #293

Open
stitam opened this issue Sep 22, 2020 · 5 comments
Open

Importing functions from other packages #293

stitam opened this issue Sep 22, 2020 · 5 comments
Assignees
Labels
consistent api Uniformity across functions and data sources

Comments

@stitam
Copy link
Contributor

stitam commented Sep 22, 2020

I've recently read an interesting article about connecting to other packages:
https://kbroman.org/pkg_primer/pages/depends.html

I do revisit functions quite often to see if @importFrom or @import were added, and to me this approach seems a bit error prone. I think it would be much better to use package::function() syntax everywhere in the package and remove all instances of @import and @importFrom. What do you think?

@stitam stitam added the consistent api Uniformity across functions and data sources label Sep 22, 2020
@stitam stitam self-assigned this Sep 22, 2020
@Aariq
Copy link
Collaborator

Aariq commented Sep 22, 2020

I thought @import tags were necessary for the NAMESPACE file to be built correctly? I'll have to read some more about it.

@Aariq
Copy link
Collaborator

Aariq commented Sep 23, 2020

So I read the post, and I get it, but I'm not sure this is a big enough deal to go through the entire codebase and remove all the @import tags.

@andschar
Copy link
Contributor

I also think it's more clear to use the :: operator. I sometimes find myself not knowing to which package a function belongs. I think this is also special for R, as for example, in Python one has to always reference to the library: numpy.array([1,2,3]). However I agree with @Aariq whether this is a big enough deal to go through the whole codebase. Then again, it would be consistent.

@stitam
Copy link
Contributor Author

stitam commented Oct 1, 2020

Agree, huge work, little gain. Maybe what we can do is to keep an eye out for these when we do other stuff, and over time the functions will be naturally updated? Similarly to lintr::lint() where we don't fix the style for the package in one go but improve the style over time? Then the outcome of this issue for now would be to add a bullet to CONTRIBUTING.md.

@Aariq Aariq mentioned this issue Oct 14, 2020
@maelle
Copy link
Member

maelle commented Oct 14, 2020

https://github.com/dreamRs/prefixer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consistent api Uniformity across functions and data sources
Projects
None yet
Development

No branches or pull requests

4 participants