从 NAMESPACE 访问 S3methods 的正确方法

Question

TL；DR 版本：

为什么基本 R 方法的导出方式与 Roxygen2 作者建议您导出自己的方法的方式不同？

进一步说明：

这是对here 和here 的帖子的后续问题。与其用很多问题轰炸哈德利，我认为最好问问社区。​​p>

我试图更好地理解 S3method 导出的行为，因为基本 R 方法的导出方式与 Roxygen2 作者推荐的导出方式之间似乎存在不一致。

例如，stats 包中包含 plot.ts 和 plot.stepfun 方法等。你也可以edit() 或fix() 这些。但是，使用Roxygen2 的推荐工作方式，建议您使用@export 所有泛型和方法（哈德利的回答here）。

所以，假设我们有一个my_class 类的对象，我们希望创建一个适用于该类plot.my_class 的绘图函数。我们可以如下创建Roxygen2 文档：

#' plot.my_class title
#'
#' @param x An object of class 'my_class'.
#'
#' @export
plot.my_class <- function (x, ...) # some magic

这会生成NAMESPACE 条目

S3method(plot,my_class)

现在，当我安装包时，当我在search()的包位置上使用ls()时，我将无法看到方法plot.my_class，我也无法看到edit()或fix()它（我可以使用getAnywhere())。显然，这与基本 R 函数的行为不同，因为我可以 edit(plot.ts) 并看到它列在 stats 包命名空间中。我能看到解决这个问题的唯一方法是在我的Roxygen2 文档中明确地@export plot.my_class，例如

#' plot.my_class title
#'
#' @param x An object of class 'my_class'.
#'
#' @export plot.my_class
plot.my_class <- function (x, ...) # some magic

这会生成 - 明显错误 - NAMESPACE 条目

export(plot.my_class)

Hadley 说使用 edit() 或 fix() 是个坏主意。我理解其中的一些原因（也许有人可以扩展一点？）但它们对于调试目的很有用，因为我正在使用的函数非常复杂。

所以总结一下，为什么 base R 的方法可见而我自己的方法不可见？

Answer 1

我怀疑基本 R 包中还有许多其他不一致的原因是相同的：它是一个经过多年发展的有机系统，许多方面非常陈旧并保持与 S 语言的兼容性。

roxygen2 和其他软件包推荐的许多指导方针都源于与 R 合作多年的经验。

如果今天从头开始重写基本 R 包而不考虑向后兼容性，它们看起来会非常不同。

如果您发现自己需要edit 和/或fix 来乱搞其他人的包，那么这表明这些包有一些应该解决的主要问题。通常你不需要这样做——这就是为什么fix 是一个坏主意的部分原因：它是潜在问题的征兆。

事实上，即使使用 Hadley 推荐的导出包泛型的模式，仍然有可能（尽管更困难）破解包的非导出方法。