問題タブ [nested-generics]

これらのメソッドをまとめて、ネストされたマップを反復処理できるようにしました (別の SO の質問について)。

明確にわかるように、最初の 2 つのメソッドは、ジェネリックと、1 つの呼び出しiVと他の呼び出しを除いて、実際にはほとんど同じiiVです。それらを1つの方法に折りたたむ方法、または少なくともメカニズムの明確な複製を1つの場所に移動する方法はありますか?

正しく行われれば、任意の深さのネストされたマップを反復処理できるはずです。

ジェネリックをフープにジャンプさせる方法を見つけようとしています。

私は持っている：

そして多くの「サブタイプ」クラス:

私が望むのは、2 つの型パラメーター and を持つクラスを宣言TするSことです。TTypeSTMiddle

Sextends TAND implementsを保証するジェネリックの方法がわかりませんMiddle。私が欲しいのは次のようなものです:

また

しかし、もちろんどちらも合法ではありません。たぶん、私が見逃している魔法がありますか？

インターフェイス Value とクラス Record があります

Java はこれをコンパイルせず、Generics 宣言について不平を言います > 。これが無効な構文である理由について誰かが教えてくれますか?

だから私は素晴らしいJon Skeetのこのビデオを見ていました: http://www.youtube.com/watch?v=3DkISWIouY4 (最初から見て、私が質問しようとしている部分を見てください!)

したがって、次のコードを検討してください。

TSomething を実際の型に展開できない理由として、これが実行されないことはわかっています。<SimpleContainer<SimpleContainer<SimpleContainer<SimpleContainer...

ただし、 の定義を次のように変更するとDeepContainer<T>:

突然それは機能します。

しかし、私の考えではそうではありません。TSomething の型を展開しようとすると、次のようになるためです SimpleContainer<SimpleContainer<SimpleContainer<SimpleContainer<SimpleContainer。

これがどのように機能するのか、私には理解できません。

次の小さな Java の例は、理由が不明確なためコンパイルされません。

ctx.put を含む行は、次のエラーを生成します。

ワイルドカードなしで作業する場合、属性パターンは正常に機能します。

コンパイラがワイルドカード入力で値を受け入れない理由はありますか?

私はIntelliJ IDEAを使用しており、ブラウザーで任意の型またはメンバーの JavaDoc を開くように設定しています。IntelliJ IDEA は、パラメーターとしてジェネリック型を持つメソッドの完全な URL を推測できないようです。メソッドのドキュメントを開こうとするjava.lang.Object.isAssignableFrom(Class<?>)と、これら 2 つの URL のどちらを開く必要があるかを尋ねられます。

• file:///[...]/docs/api/java/lang/Class.html#isAssignableFrom(java.lang.Class<?>)
• file:///[...]/docs/api/java/lang/Class.html#isAssignableFrom(java.lang.Class)

メソッドの型をジェネリック パラメータでエンコードするためのこれら 2 つの競合する標準はありますか? 将来使用されるのは 1 つだけであると想定できますか (おそらく最初のもの)?

追加のボーナス: IntelliJ IDEA を設定して、デフォルトでこれらのフォームのいずれかを自動的に選択する方法はありますか?

ネストされたワイルドカード境界型を持つ境界型パラメーターを持つクラスがあります。クラスでは、バインドされたネストされたパラメーターの型を複数のメソッドで使用する必要があります。複数の場所で簡単に参照できるように、代わりにワイルドカード境界型をジェネリック型パラメーターとして定義するか、ジェネリック変数名に割り当てる方法はありますか?

クラスの実装方法は次のようになります

これは実際にはリストのタイプをフィルターのタイプに制限しませんが、私たちの状況では十分です。理想的には、リストの型は、フィルターの推論された型をメソッドの境界付き型パラメーターのように名前にバインドできる構造体を使用してフィルターの型に制限されますが、代わりにクラス レベルで制限されます。

基本的に私は次のようなことをしたいと思います

私が知っていて見つけることができることから、これは不可能ですが、これを可能にするあいまいな機能またはJava 7の新機能がおそらくあることを望んでいました. 次のような2番目の型パラメーターを指定できることは知っています

しかし、コンパイラが決定できるときに、子クラスで G を指定する必要はありません。

私が見つけることができた唯一の可能なオプション/解決策は、この質問 の解決策で指定されたファクトリメソッドを持つ浅いサブクラスを持つことですJava および Javaジェネリックのネストされた型パラメーター-同じワイルドカードを複数回使用します

私は現在、Java インターフェイスとジェネリックを使用して概念モデルの API を実装しようとしています。このモデル (Transmodel V5.0) は、エンティティー関係モデルとして詳細に記述されていますが、使用される基本タイプの一部が指定されていません。たとえば、さまざまなエンティティの識別子のタイプや、シーケンス内の順序付けを確立するために使用されるタイプは定義されていません。

API を可能な限りジェネリックに保ちたいので、ジェネリックを使用してそれらの詳細を構成するようになりました。何かが一貫していると仮定しないことを含め、型について仮定をしたくありません。各エンティティは異なる識別子タイプを持つことができ、各シーケンスは順序付けのために使用される異なるタイプを持つことができます。

私が直面している問題は、あるエンティティが別のエンティティを参照すると、複雑さが急速に増大することです。その識別子の型を渡す必要があるだけでなく、参照されるエンティティを構成するために必要なすべてのものも必要です。

たとえば、私は持っています：

私はまだそれを読んで意味をなすことができますが、少し冗長になってきています。そして、VehicleJourney のようなエンティティを他のエンティティで参照できるため、型パラメーター リストが爆発的に増加します。これは、私が考えることができる最小の重要な例です。

型システムの構成全体をモデル化する単一の Java エンティティを作成する方法はありますか? 私は、すべての識別子タイプと順序付けタイプをアタッチし、1 つとして渡すことができるものを考えています。上記の例を次のようにします。

疑問符のある場所では、VehicleJourney 識別子のタイプを CONF から何らかの方法で抽出する必要があります。それが実現可能であれば、複雑さは管理可能なレベルにとどまるはずです。