[ESS] non-exported functions, can ESS make usage more convenient?

[Chris Wallace]

Dear Paul,

it's not an ESS solution, but the R package "devtools" can be very 
helpful here, allowing you to load code from a package as if all 
functions in that package were exported.  Then ESS can be used in the 
normal way to interact with R.  This allows you to drop the ':::' 
altogether if they are only there to allow you to step through functions 
during development.

Chris

On 10/04/14 17:10, Paul Johnson wrote:
> 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
> function.
>
> 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:
>    'summary.factor'
> 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
> agree.
>
> 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.
>
> pj
>


-- 
JDRF/WT Diabetes & Inflammation Laboratory (DIL),
NIHR Cambridge Biomedical Research Centre,
Cambridge Institute for Medical Research,
University of Cambridge

Website: http://www-gene.cimr.cam.ac.uk/staff/wallace
DIL Website: http://www-gene.cimr.cam.ac.uk