我真的很想知道差异在哪里,更一般地说,找出不能使用HLists的规范用例(或者说,不会比常规列表产生任何好处).
(我知道TupleNScala 中有22个(我相信),而一个只需要一个HList,但这不是我感兴趣的那种概念差异.)
我在下面的文字中标出了几个问题.它实际上可能没有必要回答它们,它们更倾向于指出我不清楚的事情,并指导某些方向的讨论.
我最近在SO上看到了几个人们建议使用HLists的答案(例如,由Shapeless提供),包括对这个问题的删除答案.它引发了这一讨论,从而引发了这个问题.
在我看来,只有当您静态地知道元素的数量及其精确类型时,才会使用hlists.这个数字实际上并不重要,但你似乎不太可能需要生成一个包含不同但静态精确已知类型的元素的列表,但是你不能静态地知道它们的数量.问题1:你甚至可以写一个这样的例子,例如,在循环中吗？我的直觉是,拥有静态精确的hlist与静态未知数量的任意元素(相对于给定的类层次结构的任意)只是不兼容.
如果这是真的,即你静态地知道数字和类型 - 问题2:为什么不使用n元组？当然,你可以类型安全地映射和折叠一个HList(你也可以,但不是类型安全地,借助于一个元组productIterator),但由于元素的数量和类型是静态已知的,你可能只是访问元组元素直接执行操作.
另一方面,如果f您在hlist上映射的函数是如此通用以至于它接受所有元素 - 问题3:为什么不通过它使用它productIterator.map？好的,一个有趣的区别可能来自方法重载:如果我们有几个重载f的,拥有hlist提供的更强的类型信息(与productIterator相反)可以允许编译器选择更具体的f.但是,我不确定这在Scala中是否真的有用,因为方法和功能不一样.
基于相同的假设,即您需要静态地知道元素的数量和类型 - 问题4:可以在元素依赖于任何类型的用户交互的情况下使用hlists吗？例如,想象用循环内的元素填充hlist; 从某个地方(UI,配置文件,演员交互,网络)读取元素,直到某个条件成立.什么类型的hlist是什么？类似于接口规范getElements:HList [...]应该使用静态未知长度的列表,并允许系统中的组件A从组件B获得这样的任意元素列表.
我需要实现一个带有元组的泛型方法并返回一个Map示例:
val tuple=((1,2),(("A","B"),("C",3)),4)
我一直试图将这个元组分解为一个列表:
val list=tuple.productIterator.toList
Scala>list: List[Any] = List((1,2), ((A,B),(C,3)), 4)
但这种方式会返回List [Any].
我现在正在尝试找出如何迭代以下元组,例如:
((1,2),(("A","B"),("C",3)),4)
为了遍历每个元素1,2,"A",B",...等.我怎么能在元组上进行这种迭代