1. If you have time to change internal functions naming, you can rename
internal functions by putting a leading '.'.
Even without namespace, I have noticed there is no check for corresponding
docs for such functions.

2. If you don't want to rename all internal functions, the best way is
writing an 'internals.Rd' file with an alias for each internal function
(documented in 'writing R extensions').

3.Finally, you can add a NAMESPACE (see writing R extensions). However, if
you use S3/S4 classes, this can be much more tedious to do.

I think the no. 2 to be the fastest/safer way.
Antonio.

2006/6/7, Dan Rabosky <dlr32@cornell.edu>:
>
>
> Hello.
>
> I am creating an R package that I'd like to submit to CRAN (OS Windows
> XP).  How do I distinguish among 'public' functions, e.g., those that are
> intended to be called by users of the package and for which I am providing
> documentation & examples, and 'private' functions, which are used
> internally by the 'public' functions, but for which I do not wish to
> provide documentation?  The private functions are all coded in R (nothing
> in C or Fortran) and are essential to the operation of several public
> functions.
>
> I have been unable to find any documentation on this in the 'writing r
> extensions' manual', on previous posts to R-help, or through any other
> source.  One possibility is to include the source code for the 'private'
> functions within the public functions.  However, since multiple public
> functions utilize the same core set of 'private' functions, this seems
> unwieldy and redundant at best.
>
> If I simply include the source for the 'private' functions in the "R"
> directory (without corresponding *.Rd and *.html documentation in /man),
> then check the package with "R CMD check', it does appear to process the
> private functions (and successfully builds with R CMD build).  However, I
> do receive a warning for including undocumented code objects.  Is this the
> recommended approach and/or is there a better way to do this?  One
> potential problem with this approach is that - should an error occur
> within
> a private function, it may be very difficult for the user to decipher the
> nature of the problem.
>
> Any suggestions will be greatly appreciated.
> ~Dan Rabosky
>
>
>
> Dan Rabosky
> Department of Ecology and Evolutionary Biology
> 237 Corson Hall
> Cornell University
> Ithaca, NY14853-2701 USA
> DLR32@cornell.edu
> web: http://www.birds.cornell.edu/evb/Graduates_Dan.htm
>
> ______________________________________________
> R-help@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html
>

	[[alternative HTML version deleted]]

