Java,C#和TypeScript(也称为Sun / Hejlsberg语言系列)使用T
,U
,V
等来表示泛型类型参数。表面上是因为T
代表"类型",U
和V
跟随字母表中的T
。
另一方面,Scala使用A
,B
,C
等等,OCaml和Haskell使用a
,b
和{ {1}}。
这些惯例来自哪里?是因为函数式语言更接近数学证明,惯例使用c
,α
和β
?
类似,但没有回答我的问题:Where does the C# generics naming convention come from?。
答案 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
表示枚举。这些倾向于反驳你的断言,即存在一般(广泛的)T
,U
,V
约定,至少对于Java而言。显然,在没有具体指导的情况下,一些个体设计师会采用对T
指南的明显扩展(见下面的链接),但这似乎是个人选择的结果。 (并且这些团体可能会认为这不值得讨论。)
(如果您想进行详尽的搜索,请访问每个javadocs索引A-Z页面,并搜索所有出现的&#34;&lt;&#34;。)
我希望链接到旧讨论/提交/邮件列表,其中首次讨论该约定。
对于Java,我怀疑你会发现这个。讨论和邮件列表将是私有的,当将泛型添加到该语言时,Java源代码仍然关闭,以及上面的所有示例。
@Lew Bloch在Java 8中添加到Java SE的API中找到了T
,U
,V
的一些示例(见下文),作为流支持的一部分。我断言这不是一般模式,并且大量已有的类反驳了它。
一般模式或惯例的其他负面证据:
U
和V
。S
,U
和V
作为第二,第三和第四类型参数。 (不是U
,V
,W
...)最后,JLS(JLS 6.1)建议:
类型变量名称应该是精简的(如果可能的话,单个字符)但是令人回味,并且不应包括小写字母。这样可以很容易地将类型参数与普通类和接口区分开来。
容器类型应使用名称
E
作为其元素类型。地图应使用K
作为其键的类型,V
作为其值的类型。名称X
应该用于任意异常类型。我们使用T
作为类型,只要没有更具体的类型来区分它。 (通用方法通常就是这种情况。)如果有多个类型参数表示任意类型,应使用字母表中与
T
相邻的字母,例如S
。或者,它可以使用数字下标(例如T1
,T2
)来区分不同的类型变量。在这种情况下,所有具有相同前缀的变量都应该下标。
简而言之,JLS中未明确提及U
和V
,但其他替代方案是。