在R中的命名空间中导入有什么好处？

Question

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 ?

Answer 1

If a function foo is imported from package Bar then it is found regardless of what the user does to their search path, eg, 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).