Tag: hlist

HL主义者只不过是一种复杂的写作方式而已?

我真的有兴趣找出差异在哪里,更一般地说,是要确定不能使用HList的规范用例(或者说,不会比常规列表产生任何好处)。 (我知道在Scala中有22个(我相信) TupleN ,而一个只需要一个HList,但这不是我感兴趣的那种概念差异。) 我在下面的文字中标出了几个问题。 实际上可能没有必要回答这些问题,他们更多的是指出我不清楚的事情,并指导讨论在某些方面。 动机 我最近在SO上看到了一些关于人们build议使用HList(例如, Shapeless提供的)的答案,包括删除了这个问题的答案。 这引起了这个讨论 ,这又引发了这个问题。 介绍 在我看来,只有当你知道元素的数量和它们的精确types时,列表才是有用的。 这个数字实际上并不重要,但是您似乎不太可能需要生成一个列表,其中包含不同但静态精确的已知types的元素,但是您不会静态地知道它们的数量。 问题1:你甚至可以写这样一个例子,例如,在一个循环? 我的直觉是,具有静态未知数的任意元素(相对于给定的类层次结构是任意的)的静态精确的hlist只是不兼容。 HLists与元组 如果这是真的,也就是说,你静静地知道数字和types – 问题2:为什么不使用一个n-元组? 当然,你可以types化地映射和折叠一个HList(你也可以,但不能types化,在productIterator的帮助下通过一个元组来完成),但是因为元素的数量和types是静态的,所以你可能只需要访问元组元素直接执行操作。 另一方面,如果你在hlist上映射的函数是通用的,它接受所有的元素 – 问题3:为什么不通过productIterator.map使用它? 好的,一个有趣的差异可能来自方法重载:如果我们有几个重载的f ,具有由hlist提供的更强types信息(与productIterator相比)可以允许编译器select更具体的f 。 但是,我不确定这是否会在Scala中起作用,因为方法和函数是不一样的。 HLists和用户input 基于相同的假设,即你需要静态地知道元素的数量和types – 问题4:在元素依赖于任何types的用户交互的情况下,能否使用它? 例如,想象用循环内的元素填充一个hlist; 元素是从某处(UI,configuration文件,演员互动,networking)读取,直到某个条件成立。 什么样的Hlist是什么? 类似于接口规范getElements:HList,它应该与静态未知长度的列表一起工作,并且允许系统中的组件A从组件B获得这样的任意元素的列表。