Question

我用 pkgs::function表示法访问另一个包中的函数。这有时会导致类似survival包中的问题：

data(logan,package="survival")
resp <- levels(logan$occupation)
n <- nrow(logan)
indx <- rep(1:n, length(resp))
logan2 <- data.frame(logan[indx,],
                     id = indx,
                     tocc = factor(rep(resp, each=n)))
logan2$case <- (logan2$occupation == logan2$tocc)
survival::clogit(case ~ tocc + tocc:education + survival::strata(id), logan2)

它给出错误： Error in eval(expr, envir, enclos) : could not find function "coxph"

coxph是另一个从clogit函数内部调用的函数。可以避免这种情况吗？我不想将包附加到搜索路径，即根据Hadley的library(survival)最佳做法使用advanced r。

Answer 1

（扩大@ RichScriven上面的评论。）

我不完全确定 Advanced R 中的哪个位置“不要使用library()”作为最佳做法。也许在Functions section（请编辑你的问题，以澄清我是否有错误的位置！），其中说：

最容易理解和推理的函数是纯函数：始终将相同输入映射到同一输出并且对工作区没有其他影响的函数。换句话说，纯函数没有副作用：除了它们返回的值之外，它们不会以任何方式影响世界的状态。

... [指出library()是一个不纯的函数，因为它改变了搜索路径] ...

通常最好尽量减少副作用的使用，并在可能的情况下，通过将纯净的功能与不纯的功能分开来最小化副作用的足迹。

请注意这里松散的措辞：“通常最好尽量减少......尽可能减少......”这并不意味着“不要使用library()”...... 有意义的是，您不希望将library() 放入函数或包内。如果你正在使用一个包，你可以（应该？）使用@importFrom survival clogit coxph代替...我发现将@importFrom标记放在每个函数的开头可以很好地标记外部其中使用的功能我不一定需要::来识别外国功能（你的里程可能会有所不同）。

但是，如果你实际上编写代码来进行生存分析那么~~向后弯腰~~会花费很大的精力来避免library(survival)似乎没必要。

在上面放大@ PierreLafortune的评论：clogit内部包含代码coxcall[[1]] <- as.name("coxph")。如果此行已更改为coxcall[[1]] <- as.name("survival::coxph")，您的代码可能会按原样运行。如果您感觉足够强烈，可以发布issue request on Github about this ...

Answer 2

做survival::coxph->coxph。在这里，您只需在环境中创建一个具有相同名称的新功能，以便clogit找到新功能。

使用另一个包中的函数而不附加到搜索路径？

2 个答案: