On 12/06/2013 10:44 AM, Bryan Hanson wrote:
[previously posted on Stack Overflow:
http://stackoverflow.com/questions/17034309/hiding-undocumented-functions-in-a-package-use-of-function-name
]
I've got some functions I need to make available in a package, and I don't want
to export them or write much documentation for them. I'd just hide them inside
another function but they need to be available to several functions so doing it
that way becomes a scoping and maintenance issue. What is the right way to do
this? By that I mean do they need special names, do they go somewhere other
than the R subdirectory, can I put them in a single file, etc? I've checked out
the manuals (e.g. Writing R Extensions 1.6.1), and what I'm after is like the
.internals concept in the core, but I don't see any instructions about how to
do this generally.
For example, if I have functions foo1 and foo2 in a file foofunc.R, and these
are intended for internal use only, should they be called foo1 or .foo1? And
the file that holds them, should it be .foofunc.R or foofunc-internals? What
should the Rd look like, or do I even need one?
I know people do this in packages all the time and I feel like I've seen this
somewhere, but I can't find any resources just now. Perhaps a suggestion of a
package that does things this way which I could study would be sufficient.
The best way to do this is simply not to export those functions in your
NAMESPACE file. If you want to use a naming convention
internally to remind yourself that those are private, you can do so, but
R doesn't force one on you, and there are no really popular conventions
in use. R won't complain if you don't document those functions at all.
There may have been other advice in the version 1.6.1 manual, but that
is seriously out of date, more than 10 years old. I recommend that you
update to 3.0.1.
Duncan Murdoch
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
