Clear list of functions in package R with many functions

Question

[Revised based on the proposal to export names.] I worked on the R package, which comes close to about 100 functions, possibly more.

I want to have, say, 10 visible functions, and each can have 10 "invisible" sub-functions.

Is there an easy way to choose which features are visible and which are not?

Also, in the interest of avoiding diff, is there an all.equal command that can be applied to two different packages to see where they differ?

Answer 1

You can make a file called NAMESPACE in the base directory of your package. In this case, you can determine which functions you want to export to the user, as well as import functions from other packages. Exporting will make the function usable, and importing will transfer you the function from another package without making it available to the user (useful if you just need one function and you do not want your users to download another package when they download yours).

The final part of my NAMESPACE packages:

useDynLib(qgraph) export(qgraph) (...) importFrom(psych,"principal") (...) import(plyr) 

which accordingly loads the compiled functions, makes the qgraph() function available, imports the principal function from psych and imports from plyr all the functions that are exported to plyr NAMESPACE.

Read more:

http://cran.r-project.org/doc/manuals/R-exts.pdf

Answer 2

The answer is almost certainly to create a package. Some rules of thumb may help design choices:

• The package should solve one problem.
• If you have functions that solve another problem, put them in a separate package

For example, check out the ggplot2 package:

• ggplot2 is a package that creates beautiful graphics.
• It imports plyr , a package that provides consistent syntax and an approach to solve the problems of Split, Apply, Combine.
• It depends on reshape2 , a package with several features that turn big data into long data and vice versa.

The fact is that all these packages were written by one author, that is, Hadley Wickham.

If you decide to make a package, you can control the visibility of your functions:

• Only exported functions are displayed directly in the namespace
• You can additionally mark some functions with the internal keyword, which will prevent them from appearing in automatically generated function lists.

If you decide to develop your own package, I highly recommend the devtools package and read the devtools wiki

Answer 3

I think you should organize your package and code as you feel most comfortable with; this is your package after all. NAMESPACE can be used to control what is opened or not to the user, as others have mentioned, and you do not need to document all the functions, only the main user-defined functions, adding \alias{} tags to the Rd files for all the support functions that you are not You want people to know or hide too much on the package.internals.Rd page.

Speaking of which, if you want people to help you develop your package or work with it and do amazing things, the better organized it will be easier. Thus, lay out your functions logically, perhaps one file per function, named after the name of the function, or group all related functions into one R file, for example. But be consistent in what approach you do.

If you have common functions that are more widely used, consider splitting these functions into a separate package that others can use, without having to rely on your mega package with an additional hard drive that is more specific. Then your package may depend on this general package, as well as on packages of other authors. But do not break packages just to make them smaller.

Answer 4

If your reformulated question is about “a way to organize large packages,” this may apply:

• NAMESPACE allows you to export functions very finely: your user will see 10 visisble functions

• even an invisible function is available if you or users are known, "which are executed using the operator ::: triple colon operator

• bags have all sizes and shapes; one general rule about when to split can be that as soon as you have use functionality in different contexts

Regarding diff on packages: Ah? Packages are usually not that close, so you need a comparison function. The diff really useful in the source code. You can use the hash function for binary if you want, but I'm still puzzled by why this is needed.