Scala中类型类的命名约定是什么？
发布时间：2020-12-16 09:22:43 所属栏目：安全 来源：网络整理
导读：在Java世界中,接口的命名约定已经很成熟了.例如,当你说某些类实现了可比较的接口时,可以说它的对象是可比的.然而,类型类的命名约定并没有很好地建立起来.例如,Int具有数值隐式可用,因此您可以说“Int是数值类型”.但是那里有类型排序.我不明白为什么选择这个
|
在Java世界中,接口的命名约定已经很成熟了.例如,当你说某些类实现了可比较的接口时,可以说它的对象是可比的.然而,类型类的命名约定并没有很好地建立起来.例如,Int具有数值隐式可用,因此您可以说“Int是数值类型”.但是那里有类型排序.我不明白为什么选择这个名字. “Int是一种订购类型”没有任何意义.也许它应该被读为“Int类型有订购”.然后在Scalaz有平等和显示.我完全不知道为什么选择这些名字(除了他们在Haskell中这样).我试着看Haskell,类型的母语,这是一个很好的命名约定,但发现并不存在任何东西. Haskell的家伙似乎并不关心名字(这是我从邮件列表讨论中收集到的).但是来自Java世界,我关心的是名字.我不太习惯于“类型说一切”的范例.
问题是：你所遵循的命名约定,如果你所做的,为命名类型？ 解决方法
实际上,事情在Haskell中是很简单的：类型类通常根据操作代表什么来命名,而不是类型参数代表什么.
例如： >阅读,显示：定义了标准字符串序列化/反序列化功能的类型类. 一些示例不是很好：例如,Num是一类类型的类型,其中定义了一个模糊算术运算的ad-hoc集合,但是没有任何理由Num实例实际上是任何一个数字常规意义.这也许可以被称为“支持数字操作的类型”,假装“数字”实际上意味着该短语中的任何内容. 简而言之,Numeric可能是模仿的一个很好的例子,如果类型类只有一个函数(可能有多个变体),那么在该函数之后命名类几乎总是安全的,就像show vs. Show一样. 但实际上,主要的是根据类型类的功能来考虑,而不是类型参数.认为动词,而不是名词.名词是愚蠢的惰性的东西,所以在行动和操作方面的想法可能导致更好的程序设计. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
推荐文章
站长推荐
热点阅读