4
HLists只不过是一种复杂的编写元组的方式吗？
我真的很想找出差异所在，并且更一般地说，是找出无法使用HLists的规范用例（或者，与常规列表相比不会产生任何好处）。 （我知道，TupleNScala 中有22个（我相信），而一个人只需要一个HList，但这不是我感兴趣的概念差异。） 我在下面的文字中标记了几个问题。可能实际上没有必要回答这些问题，它们更多的是指出我不清楚的事情，并在某些方向上指导讨论。 动机 我最近在SO上看到了几个答案，人们建议使用HLists（例如，由Shapeless提供），包括对此问题的删除答案。这引起了讨论，从而引发了这个问题。 介绍 在我看来，仅当您静态地知道元素的数量及其精确类型时，hlist才有用。该数字实际上并不是至关重要的，但似乎不太可能需要生成包含变化但静态精确知道的类型的元素的列表，而您却不能静态地知道它们的数量。问题1：例如，您是否可以编写一个循环示例？我的直觉是，拥有静态精确的hlist和静态未知数量的任意元素（相对于给定的类层次结构是任意的）只是不兼容的。 HList与元组 如果是这样，即您静态地知道数字和类型- 问题2：为什么不只使用n元组呢？当然，您可以安全地在HList上进行类型映射和折叠（也可以但不能进行安全地在HList上进行类型化productIterator），但是由于元素的数量和类型是静态已知的，因此您可以访问元组元素直接执行操作。 另一方面，如果f您在hlist上映射的函数是如此通用，以至于它接受所有元素- 问题3：为什么不通过productIterator.map？好的，方法重载可能是一个有趣的区别：如果我们有几个重载f的方法，则由hlist提供的更强的类型信息（与productIterator相比）可以使编译器选择更具体的f。但是，由于方法和函数不同，我不确定在Scala中是否真的可以使用。 H列表和用户输入 基于相同的假设，即您需要静态了解元素的数量和类型- 问题4：在元素依赖于任何类型的用户交互的情况下，可以使用hlists吗？例如，想象一下用循环内的元素填充hlist；从某个位置（UI，配置文件，actor交互，网络）读取元素，直到满足特定条件为止。hlist的类型是什么？与接口规范getElements类似：HList [...]应该与静态未知长度的列表一起使用，并允许系统中的组件A从组件B获取此类任意元素的列表。