[ESS] non-exported functions, can ESS make usage more convenient?
pauljohn32 at gmail.com
Thu Apr 10 18:10:16 CEST 2014
This is another case where I don't understand the computer science-y
words you guys use and so I can't understand the documentation that's
right in front of me. I think...
The question now is how to develop functions using non-exported
functions from one's own package. My code in the rockchalk package
has quite a few "rockchalk:::" usages. I put those things in there
because the functions are not exported. It is not possible to write
new functions or to "step through" a function's code without manually
inserting the package name :::. I had thought those usages were
actually beneficial because the eliminate the R runtime lookup for the
R 3.1 package builder now gives warnings about usages like that.
There are ::: calls to the package's namespace in its code. A package
almost never needs to use ::: for its own objects:
See the information on DESCRIPTION files in the chapter 'Creating R
Is this the kind of thing that ESS developer mode is designed to help?
While I'm asking, I have this related problem ALL THE TIME. Somebody
else's package has a problematic function in it. So what I do is get
their code and interactively revise the function so it works better.
Then I use assignInNamespace to put my new function in place of their
function during the runtime experience so I can see if this works.
I've done this to try to persuade some packagers that I am smarter
than they are. If I can get the same result much faster, they usually
While doing that, however, I run into the same problem that
non-exported functions that are called inside those functions fail,
and I have to go in manually and insert package:::function everywhere.
Either I have to do that, or one-by-run read their non-exported
functions into memory.
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
More information about the ESS-help