http://www.keittlab.org/
On Mon, Jun 27, 2016 at 4:46 PM, Tim Keitt <tke...@utexas.edu> wrote: > > > http://www.keittlab.org/ > > On Mon, Jun 27, 2016 at 10:19 AM, Duncan Murdoch <murdoch.dun...@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 <jorism...@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" <tke...@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@r-project.org mailing list >>> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>> >> >>> > >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>> >> >> >> > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
