What is the benefit of import in a namespace in R?
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 quest开发者_如何学运维ion is, what is the benefit of importing functions like plot
, optim
or qchisq
?
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).
精彩评论