Java Generics, eng begrenzter Parametertyp

8

Ich möchte eine Methode haben, die eine Unterschrift hat wie     %Code% so dass T2 ein T1 und / oder T1 ein T2 ist. Ich will nicht, dass T1 und T2 beide ein T sind, aber keiner der beiden ist. Ich wünsche, dass der am meisten erlaubte Typ oben durch den höchsten von T1 oder T2 im Vererbungsbaum begrenzt wird. Ich benutze Java 6.

Im Folgenden wird versucht, einige gewünschte Anwendungsfälle zu zeigen.

%Vor%

Ich weiß, dass ich mit einer Signatur Ähnliches erreichen kann     %Code% aber das zwingt den Programmierer, den höchstzulässigen Typ explizit zu erwähnen, wenn ich es von der Sprache ableiten möchte.

Beachten Sie, dass die nähere Lösung nicht einfach überladen werden kann, weil ihre Löschungen die gleichen sind.

Ich hoffe, ich habe genügend Informationen zur Verfügung gestellt, um zu vermitteln, was ich will. Ich weiß, dass dies in Java vielleicht unmöglich ist, aber ich hoffe, dass es machbar ist. Dies ist auch meine erste Frage in diesem Forum, also wenn ich unwissentlich gegen Regeln verstoßen habe, entschuldige ich mich im Voraus und schätze Ihre Geduld!

    
micseydel 10.12.2013, 18:59
quelle

1 Antwort

2

Das wurde zu lang für einen Kommentar.

Aus der Perspektive des Compilers ist eine Einschränkung, die möglicherweise falsch ist, überhaupt keine Einschränkung und wird nicht helfen, herauszufinden, welche Typen in den verschiedenen Parameter-Slots erlaubt sein sollten oder was Sie damit machen dürfen Sie. Daher hat die Sprache (übrigens weder C # noch Java) keine Syntax, um Dinge auf diese Weise zu definieren. Der Grund für das Zulassen der Typabhängigkeiten besteht darin, dass Sie die Variable so behandeln können, als ob sie im Hauptteil der Methode vorhanden wäre. Also:

%Vor%

Kompiliert und ausgeführt, weil alle Collection Unterklassen eine size() Methode haben. Das Problem ist, dass <T extends S || S extends T> (oder welche andere erfundene Syntax) nicht hilft .

Nehmen wir zum Beispiel an, wir hätten folgendes:

%Vor%

Können wir in diesem Beispiel b.removeRange(...) aufrufen? Wir haben keine Ahnung , weil S möglicherweise nicht und ArrayList ist. Wie wäre es mit a.size() ? Auch das wissen wir nicht, weil T möglicherweise kein List ist. Das ist also nicht besser definiert, als wenn wir nur gesagt hätten

%Vor%

Hinzufügen, dass sie möglicherweise von einander ableiten hinzugefügt nur eine zusätzliche Komplexitätsebene zu diesem Beispiel.

    
Ian McLaird 10.12.2013 23:50
quelle