在 R 的命名空间中导入有什么好处? [英] What is the benefit of import in a namespace in R?

问题描述

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

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.

一个好处似乎是，可以使用其他包中的功能而无需附加包，从而节省内存.这在编写 R 扩展的 1.6.4 部分中举例说明手册.

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.

但是，导入功能肯定还有其他好处.特别是 部分1.6.6(处理 S4 类) 显示了 stats4 包的 namespace:

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)

这里有导入的函数既不是 S4 类也不是泛型(使用 import 也是有意义的，如 那个部分)，但是像 plot 这样的功能来自R 启动时自动加载的 graphics 包.

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.

因此我的问题是，导入 plot、optim 或 qchisq 等函数有什么好处?

Therefore my question is, what is the benefit of importing functions like plot, optim or qchisq?

推荐答案

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

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.

使用 S4(和 S3)，事情会变得相当复杂.像 graphics::plot 这样的非泛型函数可以在两个不同的包中提升为泛型(使用 setGeneric)，并且每个泛型可以附加自己的一组方法.包作者希望准确了解哪个 plot 通用，以及哪些方法调度表、它们的类和方法可以看到.

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.

使用 pkg::foo 调用函数总是解析为预期的函数.它要求 pkg 列在DESCRIPTION 文件的Depends: 字段中(可能在Imports: 中，但不从pkg 导入似乎是误导性广告)，污染了用户的搜索路径.它还涉及两个符号查找和一个函数调用 (::)，因此效率较低.我的懒惰和缺乏注意细节的部分也认为使用 :: 乏味且容易出错.

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.

包 codetoolsBioC (通过 svn 使用用户名和密码 readonly) 可以从现有包生成 NAMESPACE 文件(或者至少在最近对 R-devel 的更改在没有包的情况下引入 NAMESPACE 之前它可以；我没有在这样的包上尝试过 codetoolsBioC).

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).

这篇关于在 R 的命名空间中导入有什么好处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！