2.3 原始函数的原型

Previous: Special internals,Up: .Internal vs .Primitive

2.3 原始函数的原型

从 R 2.5.0 开始，原始函数和操作符都有原型，它们用于打印，args和扩展包检验（例如，通过tools::checkS3methods和包codetools）。在包base（和命名空间）有两个环境，和内部 S3 泛型定义的原始函数相关的 .GenericArgsEnv以及和其它相关的 .ArgsEnv。这些环境包含一个和原始函数名字一样的闭包，来自帮助页面的形式参数（手动的），一个调用UseMethod 或 NULL以及基础命名空间环境的主体。

print.default 和 args的C代码倾向使用这些环节的闭包而不是在基础环境里面定义（如原始函数）。

QC函数 undoc确认所有在这些环境中有原型的函数当前是原始函数，而不包括在内的原始函数最好看着是语言的元素（在写下面的原始时，

     $  $<-  &&  (  :    [  [[  [[<-  [<-  {  ||  ~  <-  <<-  =

     break  for function  if  next  repeat  return  while

人们可能会讨论 ~，但是解析器可以解析它而且和常规函数非常不同的语义学定义。）

QC函数 codoc 和 checkS3methods也利用这些环境（在搜索路径中，有效地把它们放置在基础环境的前面），因此codoc 把它们含有的函数形式依据帮助页面进行检验。但是，对于泛型原始函数有两个问题。第一个是大部分操作符是S3组泛型 Ops 的一部分，并且定义了它们的参数e1 和 e2：尽管很少见，一个操作符可以如"+"(e1=a, e2=b)一样调用，而且如果方法分发对一个闭包发生，将有一个参数名字发生错配。因此在环境.GenericArgsEnv中的定义必须使用名为e1 和 e2 的参数，尽管传统的文档时基于x 和 y 的：codoc通过 tools:::.make_S3_primitive_generic_env 做适当的调整。第二个矛盾的地方和Math 组泛型有关，其中组泛型通过参数列表(x, ...)定义，但大部分成员在默认方法中仅允许一个参数（round 和signif在默认方法中允许两个）：当然，这里需要修正。

除了阅读源代码，还没法区分一个.Internal或原始函数是内部的泛型函数：不要依赖于帮助页面（甚至存在的或者不在.GenericArgsEnv里面），因为它们不能自动检测。

Hits:Loading...