[R-pkg-devel] Force namespace prefix for a loaded package function
tkeitt at utexas.edu
Mon Jun 27 17:08:15 CEST 2016
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.)
> 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
>> 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(...)
>> but I would prefer reusing the namespace prefix syntax.
>> This would also avoid name collisions between package, which ideally is
>> 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
>> Or am I missing something obvious here.
>> [[alternative HTML version deleted]]
>> R-package-devel at r-project.org mailing list
[[alternative HTML version deleted]]
More information about the R-package-devel