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

[Martin Maechler]

>>>>> Chris Wallace <chris.wallace at cimr.cam.ac.uk>
>>>>>     on Mon, 14 Apr 2014 10:04:02 +0100 writes:

    > 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.

Even simpler than devtools, though not as comprehensive maybe,
is to use

  attach(asNamespace("<pkg>"))

This won't work always, notably with S4 methods, in all respects
when your package imports stuff carefully from other packages,
or exports things in special ways, 

but I'm not sure Hadley's devtools really work flawlessly in such cases.

Martin


    CW> 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
    >> 


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

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

    CW> ______________________________________________
    CW> ESS-help at r-project.org mailing list
    CW> https://stat.ethz.ch/mailman/listinfo/ess-help