Datentypen Konstruktor mit generischen Parametern überladen

[Miikku]

Hi!

Ich denke durch ein Codebeispiel ist meine Frage schon ziemlich genau beschrieben:

class MyClass extends ArrayList<String>{
	public MyClass(ArrayList<Integer> list){
		super();
		for( Integer i : list ){
			this.add(String.valueOf(i));
			this.aStrangeMethod();
		}
	}
	public MyClass(ArrayList<String> list){
		super(list);
	}
	public void aStrangeMethod(){
		// Compiled code ...
	}
}

Wobei die eigentliche Frage eher lautet:
Wenn das so nicht geht, wie dann?
Unsaubere Lösungen wie einen weiteren nutzlosen Parameter anzuhängen sind mir auch schon eingefallen, aber ich suche nach etwas sauberem.

[edit]Es geht mir bei dem ganzen eher um ein generelles Konzept zum ersetzen von überladbaren generischen Parametern und die Frage, warum sie nicht existieren. Weniger um die Lösung dieses Falles, der als einzelnes betrachtet ja ganz einfach zu lösen ist.[/edit]

Freue mich auf Antworten,

mit freundlichen Grüßen,

Miikku

 

[java62]

Du könntest doch sowas hier machen:

public MyClass(ArrayList list){
        super();
        for( Object o : list ){
            this.add(o.toString());
            this.aStrangeMethod();
        }
}

Ansonsten: Type Erasure :rtfm:

 

[0x7F800000]

Erstmal erscheint es mir suspekt, dass du überhaupt von ArrayList ableitest: in 99.9999% der Fälle würde man die ArrayList einfach als member mit an Bord nehmen, es sei denn man will wirklich eine neue, auf ArrayList basierende da6tenstruktur entwerfen (ich wüsste aber nicht, welche ???:L )

Wenn das so nicht geht, wie dann?
Unsaubere Lösungen wie einen weiteren nutzlosen Parameter anzuhängen sind mir auch schon eingefallen, aber ich suche nach etwas sauberem.

Es geht einfach nicht. Java löscht die generischen Typen, sie sind einfach nicht da, und die konstruktoren werden nicht mehr unterscheidbar. Sorge irgendwie dafür, dass die Signatur unterschiedlich wird, verwende evtl. unterschiedlich benannte factory-methoden.

Es geht mir bei dem ganzen eher um ein generelles Konzept zum ersetzen von überladbaren generischen Parametern und die Frage, warum sie nicht existieren.

Anfangs gab's bei Java keine Generics, die wurden erst ab 1.5 eingebaut. Um die Rückwärtskompatibilität zu bewahren, musste man die JVM so lassen, wie sie war, und sich damit begnügen, dass man beim compilen ein paar zusätzliche checks durchführen kann, und anschließend alles durch Object ersetzen muss.

 

[Spacerat]

Also mit der Methode von java62 lässt sich schon was anfangen, solange der eigentlich geforderte Typ ein String ist (jedes Object hat eine toString()-Methode). Seit 1.5 ist aber

public MyClass(ArrayList<? extends Object> list){
        super();
        for( Object o : list ){
            this.add(o.toString());
            this.aStrangeMethod();
        }
}

um einiges feiner, selbst wenn es relativ überflüssig ist.
Java hat leider auch so viele Kinderkrankheiten gehabt, die einem heute erst auffallen und wegen der Abwärtskompatibilität leider nicht mehr auszumerzen sind. Aber davon mal ab... wer empfiehlt heute noch die Verwendung einer pre 1.5 JVM und weswegen besteht man darüberhinaus auch noch auf diese Abwärtskompatibilität. Faktisch dürfte ein Objekt gar keine "toString()"-Methode haben, weil sie standardmässig eh' nur unsinniges Zeugs liefert (KlassenName@INSTANCEID). Okay, das sagt dem Entwickler zwar im Zweifelsfalle, dass etwas vergessen wurde aber mehr auch nicht.
Zurück zum Beispiel: Setzt man für den eigentlich verwendeten Typ nämlich etwas anderes als String (also Klassen, die "toString()" nicht überschreiben) ein, z.B. Component, kann man "Object.toString()" kaum bzw. gar nicht mehr sinnvoll einsetzen. Irgend wann ist es sinnvoll, sich von Altlasten die keiner mehr benötigt, zu trennen. Aber nee... Die Entwickler von PHP z.B. übernehmen diese celeblale Diarrhoe auch noch.