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

问题描述

R的命名空间机制允许一个export函数，然后这些函数对用户可见.此外，它还允许import来自其他软件包的功能.出口带来的好处是显而易见的，但在理解进口带来的好处方面，还有更多的问题.

似乎有一个好处，那就是可以使用其他程序包中的功能而无需附加该程序包，从而节省了内存.在写作R扩展的 1.6.4中对此进行了举例说明.手册.

但是，导入功能还必须具有其他好处.特别是部分1.6.6(处理S4类)显示stats4软件包的namespace:

 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类也不是泛型(如解决方案

如果从包Bar导入了函数foo，则无论用户对其搜索路径做了什么，都可以找到它，例如，通过附加包Baz还具有功能foo.如果没有名称空间，则软件包代码会突然使用Baz::foo来查找自身.还存在效率问题(foo会立即发现，而不是在搜索路径中的所有符号之后都会发现)，但是对于大多数应用程序来说，这些问题可能微不足道.同样，importFrom是import的改进，因为它减少了冲突(或使用了意外功能)，并且查找效率更高.

使用S4(和S3)会变得非常复杂.像graphics::plot这样的非泛型函数可以在两个不同的包中提升为泛型(使用setGeneric)，并且每个泛型都可以具有自己的一组方法.程序包作者将希望精确地了解哪些plot泛型，以及由此可见的哪些方法调度表，其类和方法.

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

包 codetoolsBioC (通过用户名和密码为)可以从现有程序包中生成一个NAMESPACE文件(或者至少可以在最近的R-devel更改在没有一个程序包的情况下在其上引入NAMESPACE；我没有在这种程序包上尝试过codetoolsBioC).

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?

解决方案

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

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