[Rd] how to keep the documents of private functions private

[Yanming Di]

First time posting on this forum.

The short version of the question is how to keep the documents of private 
(unexported) functions private. It seems that the documents of the private 
functions will be compiled into the user manual even if the corresponding 
functions are not exported. Is there a solution to this? I want to have 
documents for these functions for my own use, but I don’t want to release 
them to distract end users.

To provide some background, a more general question is how to manage unexported 
(private) functions in an R package. I need to call them during the developing 
phase or even after the package is released (e.g., for debugging purpose or 
they may be needed by new functions), but I don’t want to export them (I’d 
like to keep the number of exported (public) functions to a minimum and present 
the users with only the functions that they need to know.) 

I know I can call private functions by packagename:::fcn(), but that seems a 
little bit tedious. 

A solution I came up with is to prepare two NAMESPACE files and switch between 
them. When releasing the codes, use the thin version; when developing the 
package, use the version that export all functions. That works except if I have 
documents (Rd files) for the private functions, they will be compiled to the 
user manual even if the corresponding functions are not exported. Is there a 
solution around this? (I think I can keep two separate man folders and switch 
between them, but that seems a little bit tedious). 

Thanks.

Yanming



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] alternative to .Fortran("dqrls", ...)

[Yanming Di]

Hi all,

In a package I maintain, I use the "dqrls" from the base package to fit 
regression models. However, I was informed that directly calling functions 
from the base package is no longer allowed:


"CRAN packages should use only the public API. Hence they should not use
entry points not declared as API in installed headers nor .Internal()
nor .Call() etc calls to base packages. Such usages can cause packages
to break at any time, even in patched versions of R."

Prof. Ripley suggested that one can replace such calls with lm.wfit, which 
will work.


However, in my package, the call will need to be implemented hundreds of 
thousands times. Using lm.wfit is much slower. I am wondering whether there 
is alternative ways that are more efficient. I can program in C if needed.


Many thanks.

Best regards,
Yanming

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel