4
HListはタプルを書く複雑な方法にすぎませんか？
違いがどこにあるのか、より一般的には、HListを使用できない（または、通常のリストに比べてメリットがない）正規のユースケースを特定することに本当に興味があります。 （私はTupleNScala には22（私は信じている）があることを知っていますが、1つは単一のHListを必要とするだけですが、それは私が興味を持っている種類の概念の違いではありません。） 以下のテキストにいくつか質問をマークしました。実際にそれらに答える必要はないかもしれません、彼らは私に不明瞭なことを指摘し、特定の方向に議論を導くためのものです。 動機 私は最近、人々が（によって提供されるように、例えばHListsを使用することが提案SO上の回答のカップルを見てきました型崩れを削除答えを含む）、この質問を。それがこの議論を引き起こし、それが今度はこの疑問を引き起こしました。 はじめに 要素の数とその正確なタイプを静的に知っている場合にのみ、hlistが役立つように思えます。数は実際には重要ではありませんが、静的に正確に認識されているさまざまなタイプの要素を含むリストを生成する必要がある可能性は低いですが、静的にその数がわかっていません。質問1：そのような例を、たとえばループで書くことさえできますか？私の直感は、静的に不明な数の任意の要素（特定のクラス階層に対して任意）を持つ静的に正確なhlistを持つことは互換性がないということです。 HListsとタプル これが真である場合、つまり、静的に数値と型を知っている場合- 質問2：なぜnタプルを使用しないのですか？確かに、あなたはtypesafelyマッピングすることができますし、（あなたもすることができますが、HList折り重なっていないの助けを借りて、タプルを超える行うtypesafely、 productIterator）が、要素の数と種類は静的にあなたはおそらくタプル要素にアクセスする可能性が知られているので、直接操作を実行します。 一方、fhlistにマップする関数が非常に一般的で、すべての要素を受け入れる場合- 質問3：なぜそれを使用しないのproductIterator.mapですか？わかりました、興味深いオーバーロードの1つは、メソッドのオーバーロードにf起因する可能性がありますf。複数のオーバーロードがあった場合、（productIteratorとは対照的に）hlistによって提供されるより強力な型情報があると、コンパイラはより具体的なを選択できます。ただし、メソッドと関数は同じではないため、Scalaで実際に機能するかどうかはわかりません。 HListとユーザー入力 同じ前提に基づいて、つまり、要素の数とタイプを静的に知る必要があるということ- 質問4：要素が何らかのユーザーの操作に依存している状況でhlistを使用できますか？たとえば、hlistにループ内の要素を入力することを想像してください。要素は、特定の条件が満たされるまでどこか（UI、構成ファイル、アクターの相互作用、ネットワーク）から読み取られます。hlistのタイプは何ですか？インターフェース仕様getElements：HList [...]と同様に、静的に不明な長さのリストを処理し、システム内のコンポーネントAがコンポーネントBから任意の要素のそのようなリストを取得できるようにします。