On Jun 12, 2013, at 16:34, Bryan Hanson <han...@depauw.edu> wrote:
> Thanks Duncan... > > Silly me, it's section 1.6.1 not version 1.6.1! > > So this warning from check is not a problem in the long run: > > * checking for missing documentation entries ... WARNING > Undocumented code objects: > ‘ang0to2pi’ ‘dAB’ ‘doBoxesIntersect’ ... > All user-level objects in a package should have documentation entries. What does your NAMESPACE file say? MW > > if I understand correctly. I guess the reason I didn't find any > documentation is the wide lattitude which is possible. > > Thank you. Bryan > > On Jun 12, 2013, at 10:57 AM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > >> 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. ______________________________________________ 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.
