Scala中类型类的命名约定是什么？

Question

在Java世界中,接口的命名约定已经非常成熟.例如,当你说某个类实现了接口时Comparable,可以说它的对象是可比较的.但是,类型类的命名约定并不是那么完善.例如,Int有一个Numeric隐式可用,所以你可以说" Int是一个Numeric类型".但是那时有类型类Ordering.我不明白为什么选择这个名字." Int是一种Ordering类型"没有任何意义.也许它应该被解读为" Int类型有一个Ordering".然后有Scalaz Equal和Show.我完全不知道为什么选择这些名称(除了它们在Haskell中是这样的.)我试着查看类型的母语Haskell,以获得一个好的命名约定,但发现它确实没有.Haskell家伙似乎并不关心名字(这就是我从邮件列表讨论中收集的内容).但是来自Java世界,我确实关心名字.我不太习惯于"类型说出一切"的范例.

问题是:如果你做的话,你会遵循哪些命名约定来命名类型类？

Answer 1

实际上,Haskell中的事情大多是直截了当的:类型类通常根据操作所代表的内容来命名,而不是类型参数所代表的内容.

例如:

• Read,Show:为其定义标准字符串序列化/反序列化函数的类型.
• Eq,Ord:分别定义了相等和排序关系的类的类.
• Enum:定义"后继"操作的类型类,即其值可以枚举.
• Monoid,Functor,Monad:其中定义与类似命名的数学结构相关的操作类型的类.

一些例子并不是那么好:例如,Num是一类类型,在这类类型上定义了模糊算术运算的临时集合,但没有理由说Num实际上必须是任何传统意义上的数字的实例.这也许可以手动作为"支持数字操作的类型",假装"数字"实际上意味着该短语中的任何内容.

总之,Numeric可能是一个坏榜样去模仿,如果一个类型类只有一个功能(可能与它的多个变种),它几乎总是安全的该功能来命名类,与show对Show.

但实际上,主要的是根据类型类的函数来思考,而不是类型参数.想想动词,而不是名词.无论如何,名词都是愚蠢的惰性事物,所以在行动和操作方面的思考可能会导致更好的程序设计.