The namespace mechanism of R allows one to export
functions which then are visible to the user. Furthermore, it allows to import
functions from other packages. Whereas the benefit of export is obvious, I have more problems understanding the benefit of import.
One benefit seems to be, that one can use functions from other packages without attaching the package and thereby saving memory. This is exemplified in section 1.6.4 in the writing R extensions manual.
However, there must be other benefits of the import function. Especially, section 1.6.6 (that deals with S4 classes) shows the namespace
of the stats4 package:
export(mle) importFrom("graphics", plot) importFrom("stats", optim, qchisq) ## For these, we define methods or (AIC, BIC, nobs) an implicit generic: importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile, update, vcov) exportClasses(mle, profile.mle, summary.mle) ## All methods for imported generics: exportMethods(coef, confint, logLik, plot, profile, summary, show, update, vcov) ## implicit generics which do not have any methods here export(AIC, BIC, nobs)
Here there are functions imported which are neither S4 classes nor generics (where it would make sense to use import as well, as documented in the example in that section), but functions like plot
from the graphics
package which are automatically loaded when R starts.
Therefore my question is, what is the benefit of importing functions like plot
, optim
or qchisq
?
The Imports field really has nothing to do with functions imported into the namespace: it just makes sure the package is installed when your package is. It doesn't make functions available. You need to import functions in exactly the same way regardless of whether or not the package is attached.
Imports is used for packages that are needed by your package but that don't need to be loaded with library() . Packages referred to in @import or @importFrom statements in your Roxygen2 comments, or whose functions are accessed via the :: operator, should be here.
If a function foo
is imported from package Bar then it is found regardless of what the user does to their search path, e.g., by attaching a package Baz that also has a function foo
. Without a name space, the package code would suddenly find itself using Baz::foo
. There are also efficiency issues (foo
is found immediately, rather than after searching through all symbols on the search path), but these are likely to be trivial for most applications. In the same way, importFrom
is an improvement over import
because of fewer collisions (or use of unintended functions) and more efficient look-up.
With S4 (and S3) things can get quite complicated. A non-generic function like graphics::plot
can be promoted to a generic (with setGeneric
) in two different packages, and each generic can have its own set of methods attached. A package author will want to be precise about which plot
generic, and hence which methods dispatch table, their classes and methods see.
Calling a function with pkg::foo
always resolves to the intended function. It requires that pkg be listed in the Depends: field of the DESCRIPTION file (maybe in Imports: but then it seems like misleading advertising to not import from pkg), polluting the user's search path. It also involves two symbol look-ups and a function call (::
), and so is less efficient. The lazy and lack-of-attention-to-detail part of me also sees use of ::
as tedious and error prone.
The package codetoolsBioC (via svn with username and password readonly
) can generate a NAMESPACE file from an existing package (or at least it could before recent changes to R-devel introduced a NAMESPACE on packages without one; I haven't tried codetoolsBioC on such a package).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With