在 R 中的命名空间中导入有什么好处?
R 的命名空间机制允许导出函数,然后这些函数对用户可见。此外,它还允许从其他包导入函数。虽然出口的好处是显而易见的,但我在理解进口的好处时遇到了更多问题。
一个好处似乎是,可以使用其他包中的功能,而无需附加包,从而节省内存。在编写 R 扩展的 1.6.4 节中对此进行了举例说明手册。
然而,导入功能肯定还有其他好处。特别是 部分1.6.6(处理 S4 类) 显示 stats4 包的命名空间
:
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 是有意义的)还有,如 该部分),但是像 graphics
包中的 plot
这样的函数会在 R 启动时自动加载。
因此我的问题是,导入诸如 plot
、optim
或 qchisq
之类的函数有什么好处?
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
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果函数
foo
是从包 Bar 导入的,那么无论用户对其搜索路径执行什么操作,都会找到它,例如,通过附加也具有函数foo
。如果没有名称空间,包代码会突然发现自己使用Baz::foo
。还有效率问题(foo
是立即找到的,而不是在搜索路径上的所有符号之后找到),但这些对于大多数应用程序来说可能是微不足道的。同样,importFrom
是对import
的改进,因为它更少的冲突(或使用非预期函数)和更高效的查找。对于 S4(和 S3),事情可能会变得非常复杂。像
graphics::plot
这样的非泛型函数可以在两个不同的包中提升为泛型函数(使用setGeneric
),并且每个泛型函数都可以附加自己的一组方法。包作者希望准确了解哪个plot
通用,以及哪些方法调度表、它们的类和方法看到。使用
pkg::foo
调用函数始终会解析为预期函数。它要求将 pkg 列在描述文件的 Depends: 字段中(可能在 Imports: 中,但不从 pkg 导入似乎是误导性广告),从而污染用户的搜索路径。它还涉及两个符号查找和一个函数调用(::
),因此效率较低。我的懒惰和缺乏对细节的关注也认为使用::
是乏味且容易出错的。软件包 codetoolsBioC (通过 svn 使用用户名和密码
readonly< /code>) 可以从现有包生成 NAMESPACE 文件(或者至少在最近对 R-devel 的更改在没有 NAMESPACE 的包上引入 NAMESPACE 之前它可以;我还没有尝试过codetoolsBioC 就这样一个包)。
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 functionfoo
. Without a name space, the package code would suddenly find itself usingBaz::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 overimport
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 (withsetGeneric
) in two different packages, and each generic can have its own set of methods attached. A package author will want to be precise about whichplot
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).