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

R 的命名空间机制允许人们export然后对用户可见的功能。此外，它还允许import来自其他包的函数。虽然出口的好处是显而易见的，但我在理解进口的好处时遇到了更多问题。

一个好处似乎是，可以使用其他包中的功能，而无需附加包，从而节省内存。这在章节中进行了举例说明1.6.4 编写R扩展手册 http://cran.r-project.org/doc/manuals/R-exts.html#An-example.

然而，导入功能肯定还有其他好处。尤其，第 1.6.6 节（涉及 S4 类） http://cran.r-project.org/doc/manuals/R-exts.html#Name-spaces-with-S4-classes-and-methods显示了namespacestats4 包的：

 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)

这里导入的函数既不是 S4 类也不是泛型（在这些函数中使用导入也是有意义的，如示例中所述）那个部分 http://cran.r-project.org/doc/manuals/R-exts.html#Name-spaces-with-S4-classes-and-methods），但功能类似于plot来自graphicsR启动时自动加载的包。

因此我的问题是，导入像这样的函数有什么好处plot, optim or qchisq?

如果一个函数foo从包 Bar 导入，然后无论用户对其搜索路径执行什么操作，例如通过附加也具有功能的包 Baz ，都会找到它foo。如果没有命名空间，包代码会突然发现自己使用Baz::foo。还有效率问题（foo立即找到，而不是在搜索路径上的所有符号之后找到），但这些对于大多数应用程序来说可能是微不足道的。同样地，importFrom是一个改进import因为更少的冲突（或使用非预期函数）和更高效的查找。

对于 S4（和 S3），事情可能会变得相当复杂。像这样的非泛型函数graphics::plot可以提升为通用（与setGeneric）在两个不同的包中，并且每个泛型都可以附加自己的一组方法。包作者希望准确说明是哪个plot通用，因此哪些方法调度表，它们的类和方法看到。

调用函数pkg::foo始终解析为预期功能。它要求将 pkg 列在描述文件的 Depends: 字段中（可能在 Imports: 中，但不从 pkg 导入似乎是误导性广告），从而污染用户的搜索路径。它还涉及两个符号查找和一个函数调用（::），因此效率较低。我的懒惰和缺乏对细节的关注也看到了使用::乏味且容易出错。

套餐代码工具BioC https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC（通过 svn 使用用户名和密码readonly）可以从现有包生成 NAMESPACE 文件（或者至少在最近对 R-devel 的更改之前可以在没有 NAMESPACE 的包上引入 NAMESPACE 之前；我还没有在这样的包上尝试过 codetoolsBioC ）。