[R-pkg-devel] Force namespace prefix for a loaded package function
http://www.keittlab.org/
On Mon, Jun 27, 2016 at 4:46 PM, Tim Keitt <tkeitt at utexas.edu> wrote:
http://www.keittlab.org/ On Mon, Jun 27, 2016 at 10:19 AM, Duncan Murdoch <murdoch.duncan at gmail.com
wrote:
On 27/06/2016 11:08 AM, Tim Keitt wrote:
http://www.keittlab.org/ On Mon, Jun 27, 2016 at 3:22 AM, Joris Meys <jorismeys at gmail.com> wrote:
If you want to call a non exported function, you need three colons X:::f () And frankly, that is a bad idea.
I think you missed the point (and stated the obvious). A well-designed namespace feature would give control of imports to the code user, not the code writer. Right now, I have to avoid all the function names in base because I will cause a collision. If I want to have an "options" function in my package, I have to make it "pkgname_options" rather than pkgname::options, which is greatly preferable and would allow the user to decide whether they want to import it and then simply use "options" and "base::options". I've always considered this all-or-nothing approach to imports a bug in the implementation of namespaces in R. I was trying to suggest that it be fixed. (Probably should have sent this to r-devel actually.)
The base package is special, but for all other packages there's no "all-or-nothing" approach to imports, so your statement about a function named "options" doesn't really make sense. If you want to do that, just do it, and other packages that prefer your implementation to the base one can import just that one function, or do the import at run time by calling it as pkgname::options().
I know that. I mean for someone writing a script, not a package. Its all good for package writers. Its quite simple to control imports there. But not so much for someone using the package in R to write a script. You either go with package_name::object for everything or you call "library" and you get everything the packager exported. It would be nice to 1) be able to hold back some functions from being fully exported in a package and (maybe or) 2) extend the functionality of the NAMESPACE file to the user session via a set of functions.
Actually, now I see that those functions are available to the user in base (although discouraged). I'll have to study them a bit. THK
Does that make any more sense? THK
Duncan Murdoch
THK
Cheers Joris On 26 Jun 2016 19:37, "Tim Keitt" <tkeitt at utexas.edu> wrote:
It would be rather nice if we could define functions in our packages
that
must be called with the namespace prefix. I'd like to do #' @protected (or some such) f = function(...) list(...) in package scope and then library(x) f(1) # fails x::f(1) # succeeds Currently unless I am missing something, a function is either
exported to
global scope or not available. This could be done if package loading
made
two environments, one in the path and another not in the path, and
then
have the namespace prefix search both in succession. Yes, you could do #' @export x_f = function(...) list(...) library(x) x_f(1) but I would prefer reusing the namespace prefix syntax. This would also avoid name collisions between package, which ideally
is
the purpose of a namespace. I suppose also you could make two packages and list one in Imports:
but I
find that less satisfying because it requires a different namespace prefix. Or am I missing something obvious here. THK http://www.keittlab.org/ [[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel