泛型类型参数的T,U,V约定来自何处?

时间:2017-06-16 12:15:23

标签: java c# scala generics programming-languages

Java,C#和TypeScript(也称为Sun / Hejlsberg语言系列)使用TUV等来表示泛型类型参数。表面上是因为T代表"类型",UV跟随字母表中的T

另一方面,Scala使用ABC等等,OCaml和Haskell使用ab和{ {1}}。

这些惯例来自哪里?是因为函数式语言更接近数学证明,惯例使用cαβ

类似,但没有回答我的问题:Where does the C# generics naming convention come from?

1 个答案:

答案 0 :(得分:5)

在标准Java SE API中,设计人员通常选择与字体参数的含义/目的相关的单字母标识符:

  • Iterator<T> - javadoc其中T表示类型。其他示例包括ListIterator<T>Iterable<T>Comparable<T>Comparator<T>Class<T>
  • Collection<E> - javadoc其中E表示元素。各种其他集合类和接口使用E
  • Map<K,V> - javadoc其中K表示密钥,V表示值。
  • Enum<E> - javadoc其中E表示枚举。

这些倾向于反驳你的断言,即存在一般(广泛的)TUV约定,至少对于Java而言。显然,在没有具体指导的情况下,一些个体设计师会采用对T指南的明显扩展(见下面的链接),但这似乎是个人选择的结果。 (并且这些团体可能会认为这不值得讨论。)

(如果您想进行详尽的搜索,请访问每个javadocs索引A-Z页面,并搜索所有出现的&#34;&lt;&#34;。)

  

我希望链接到旧讨论/提交/邮件列表,其中首次讨论该约定。

对于Java,我怀疑你会发现这个。讨论和邮件列表将是私有的,当将泛型添加到该语言时,Java源代码仍然关闭,以及上面的所有示例。

@Lew Bloch在Java 8中添加到Java SE的API中找到了TUV的一些示例(见下文),作为流支持的一部分。我断言这不是一般模式,并且大量已有的类反驳了它。

一般模式或惯例的其他负面证据:

最后,JLS(JLS 6.1)建议:

  

类型变量名称应该是精简的(如果可能的话,单个字符)但是令人回味,并且不应包括小写字母。这样可以很容易地将类型参数与普通类和接口区分开来。

     

容器类型应使用名称E作为其元素类型。地图应使用K作为其键的类型,V作为其值的类型。名称X应该用于任意异常类型。我们使用T作为类型,只要没有更具体的类型来区分它。 (通用方法通常就是这种情况。)

     

如果有多个类型参数表示任意类型,应使用字母表中与T相邻的字母,例如S或者,它可以使用数字下标(例如T1T2来区分不同的类型变量。在这种情况下,所有具有相同前缀的变量都应该下标。

简而言之,JLS中未明确提及UV,但其他替代方案是。