我使用 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的advanced r最佳实践使用library(survival)。
（上面放大 @richscriven的评论。）
我不完全确定您在高级R 中的位置，您可以从"不要使用library()"作为最佳实践。也许在功能部分（请编辑您的问题，以澄清我是否有错误的位！）说：
最容易理解和推理的功能是纯粹的函数：始终将相同输入的函数映射到相同的输出，并且对工作空间没有其他影响。换句话说，纯粹的功能没有副作用：除了回归的价值外，它们不会以任何方式影响世界的状态。
... [指出
library()是一个不纯净的函数，因为它会更改搜索路径] ...通常是一个好主意，可以最大程度地减少副作用的使用，并在可能的情况下通过将纯净的纯净功能与不纯粹的功能分开来最大程度地减少副作用的占地面积。
在这里注意宽松的措辞："在可能的情况下最小化...最小化..."这并不意味着"永远不要使用library()" ...您不想将library() 放入函数或包装中是有道理的。如果您使用的软件包，则可以（应该？）使用@importFrom survival clogit coxph ...我发现将@importFrom标签放在我的每个功能的开头时都足以标记我不喜欢的外部功能t一定需要::来识别外国功能（您的里程可能会有所不同）。
但是，如果您实际上是编写代码以进行生存分析，然后向后弯曲 似乎不必要library(survival)。
放大 @Pierrelafortune的评论：clogit内部包含代码coxcall[[1]] <- as.name("coxph")。您的代码可能会像将此行更改为coxcall[[1]] <- as.name("survival::coxph")一样工作。如果您感觉足够强烈，则可以在Github上发布问题请求...
只是做survival::coxph->coxph。在这里，您只是在具有相同名称的环境中创建一个新功能，因此clogit应该找到新功能。