Hi, in our Berlin R User Group meeting yesterday we talked about dependencies in package development. One thing that came up is that it's a good practice to explicitly write package::function in the code. Is it worth to go through all of my package and enhance the code in all instances? Or do you think that NAMESPACE sufficiently prevents using a function with the same name from another package than intended and people reading source code should be aware of that anyways? If Answer1==YES: Should I also refer to other functions within my own package through myPackage::otherFunction? Should I do that for base packages like graphics, stats, utils, grDevices? (we have to declare them in the NAMESPACE imports, after all) What's a fast and easy way to find all the instances of 'external' function usage? I guess there must be discussions and guidelines about this, so some pointers instead of answers would be fine as well. Thanks ahead, Berry
[R-pkg-devel] double colon
4 messages · Berry Boessenkool, Uwe Ligges, Duncan Murdoch
On 29.01.2016 15:21, Berry Boessenkool wrote:
Hi, in our Berlin R User Group meeting yesterday we talked about dependencies in package development. One thing that came up is that it's a good practice to explicitly write package::function in the code. Is it worth to go through all of my package and enhance the code in all instances?
No, *if* you import anyway (see below).
Or do you think that NAMESPACE sufficiently prevents using a function with the same name from another package than intended and people reading source code should be aware of that anyways?
Yes.
If Answer1==YES: Should I also refer to other functions within my own package through myPackage::otherFunction?
Yes, *if* you only suggest the package and do not import from the namespace unconditionally, you should do that. Best, Uwe Ligges
Should I do that for base packages like graphics, stats, utils, grDevices? (we have to declare them in the NAMESPACE imports, after all) What's a fast and easy way to find all the instances of 'external' function usage? I guess there must be discussions and guidelines about this, so some pointers instead of answers would be fine as well. Thanks ahead, Berry [[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 29/01/2016 10:56 AM, Uwe Ligges wrote:
On 29.01.2016 15:21, Berry Boessenkool wrote:
Hi, in our Berlin R User Group meeting yesterday we talked about dependencies in package development. One thing that came up is that it's a good practice to explicitly write package::function in the code. Is it worth to go through all of my package and enhance the code in all instances?
No, *if* you import anyway (see below).
Or do you think that NAMESPACE sufficiently prevents using a function with the same name from another package than intended and people reading source code should be aware of that anyways?
Yes.
I'd add one caveat here: if you explicitly import things by name, this is definitely true. If you import everything from another package, then conceivably you could end up with problems: e.g. you import all of package A and all of package B. You want Fn from B, and since A doesn't have a function like that, you're fine. But later if package A adds a function called Fn, you might get in trouble and end up using the wrong one. So use importFrom(A, something) importFrom(B, Fn) rather than import(A, B) Duncan Murdoch
If Answer1==YES: Should I also refer to other functions within my own package through myPackage::otherFunction?
Yes, *if* you only suggest the package and do not import from the namespace unconditionally, you should do that.
I think Berry was referring to the case where package Foo has function Fn, and was asking whether he should use Foo::Fn within the code of package Foo. The answer to that is no. Your own locally defined functions generally have precedence over ones from other packages (unless you mess around with environments; don't do that).
Thanks for your reply, Uwe. The guy yesterday very strongly suggested it for user readability, but I wanted to get more opinions before doing so much work. (No offense, Steven). I'm not sure whether we talk about the same thing considering functions *within* the package. Say I have 'MyPackage' with 'fun_a' and also 'fun_b', which inside calls 'fun_a'. (Both exported) That wouldn't be in imports or suggests, right? Now image by unfortunate history there is 'AnotherPackage' that also has (its own and different) 'fun_a'. Is far as I remember, 'fun_b' will still call 'fun_a' from 'MyPackage'. I can't find back where I read that, though. For user readability and to be on the safe side, in the future I'll write 'MyPackage::fun_a'. (Of course, if I'm aware, I'll avoid same-name functions altogether). kind regards, Berry
Subject: Re: [R-pkg-devel] double colon To: berryboessenkool at hotmail.com; r-package-devel at r-project.org From: ligges at statistik.tu-dortmund.de Date: Fri, 29 Jan 2016 16:56:28 +0100 On 29.01.2016 15:21, Berry Boessenkool wrote:
Hi, in our Berlin R User Group meeting yesterday we talked about dependencies in package development. One thing that came up is that it's a good practice to explicitly write package::function in the code. Is it worth to go through all of my package and enhance the code in all instances?
No, *if* you import anyway (see below).
Or do you think that NAMESPACE sufficiently prevents using a function with the same name from another package than intended and people reading source code should be aware of that anyways?
Yes.
If Answer1==YES: Should I also refer to other functions within my own package through myPackage::otherFunction?
Yes, *if* you only suggest the package and do not import from the namespace unconditionally, you should do that. Best, Uwe Ligges
Should I do that for base packages like graphics, stats, utils, grDevices? (we have to declare them in the NAMESPACE imports, after all) What's a fast and easy way to find all the instances of 'external' function usage? I guess there must be discussions and guidelines about this, so some pointers instead of answers would be fine as well. Thanks ahead, Berry [[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel