generische arrays mal wieder )-;

[0x7F800000]

Hey leuts!
Sry, ist normalerweise nicht meine Art, aber anscheinend bin ich diesmal auf "der anderen seite" gelandet: ich hocke grad an einer blöden informatik hausaufgabe und komme mit diesen Generics wieder nicht klar...^^ :autsch:

Folgende Frage (zum zigtausendsten mal...):

public static <T> T[] myFunction(SomeGenericClass<T>[] array){
  T[] result=(T[]) new Object[123];
  //zeugs aus array in result umkopieren...
  return result;
}

1) warum meckert das ding denn nicht? Wenn ich SomeGenericClass<String> da übergebe, interessiert es das T drinnen in der methode doch eh nicht, weil String gelöscht wird, und dann weiß doch dadrinne niemand mehr, was T gewesen sein soll?

2) wenn ich myFunction(SomeGenericClass<String>[] array) aufrufe, warum kann ich das ergebnis nicht nach String[] gewaltsam casten, da sind doch nur strings drinne, ob der compiler das vergessen hat oder nicht braucht mich doch nicht zu interessieren, warum fliegen also trotzdm ClassCastExceptions?

Wäre echt dankbar, wenn mir jemand konkret sagen könnte, wie ich denn jetzt den gewünschten String-Array aus dieser dämlichen methode rausprügeln soll :bahnhof:

greetz, Andrey

 

[SlaterB]

> interessiert es das T drinnen in der methode doch eh nicht, weil String gelöscht wird,

warum sollte etwas wie 'String' gelöscht werden?
was verstehst du hier unter 'String' und 'löschen'?

> interessiert es das T drinnen in der methode doch eh nicht, weil String gelöscht wird,

T ist String, klare Angelegenheit

> , warum kann ich das ergebnis nicht nach String[] gewaltsam casten

ein Object[] kann nicht auf String[] gecastet werden,
ob nur Strings oder andere Objekte drin sind, kann doch nicht für das Casten relevant sein,

stell dir vor, zwei Threads haben eine Referenz auf das Objekt[],
zu einem Zeitpunkt sind nur Strings drin und ein Thread macht ein String[] draus,
kurze Zeit später schreibt ein anderer Thread, der noch die Object[]-Sicht hat, ein JFrame rein,

was soll denn in dieser Situation passieren?
nene, so nicht

edit:

public class Test
{
    static boolean get = true;

    public static void main(String[] args)
    {
        List<String>[] list = new List[1];
        for (String st : myFunction(String.class, list))
        {
            System.out.println("st: " + st);
        }
    }

    public static <T>T[] myFunction(Class<T> tClass, List<T>[] array)
    {
        T[] result = (T[])Array.newInstance(tClass, 4);
        // zeugs aus array in result umkopieren...
        return result;
    }
}

 

[Marco13]

Statt explizit das class-Objekt für den Inhalt zu übergeben, kann man auch mit array.getClass().getComponentType() arbeiten.
edit: Ach, Unfug - das übergebene ist ja garkein T-array *sich ein koffeingesöff holt*


Zu 1: Er meckert doch!? Er beschwert sich über eine "unchecked conversion". (Gut, das kann man nicht verhindern, aber man kann verhindern, dass diese unchecked conversion fatale Folgen hat...). Und 2. hat Slater ja schon beantwortet. Ein Array muss "wissen, was in ihm steckt".

 

[0x7F800000]

okay, vielen Dank für die antworten, zumindest habe ich nun (wieder mal^^) verstanden, warum es so nicht geht (und werde das wohl genauso schnell wieder vergessen da ich mich momentan ja in der programmier-pause befinde).

Die Lösung kann ich allerdings nicht mit begeisterung aufnehmen, weil diese mir schlicht und einfach zu antiintuitiv erscheint. Soll ich jetzt jedes Mal für jedes beliebig triviale Problemchen den Code mit diesen explizit übergebenen Class-Objekten aufblähen und mit diesen ganzen reflection-geschichten rumballern und so tun als würde ich wissen was ich da mache?

Mir fehlt im moment vor allem irgendwie die motivation mich in irgendetwas reinzudenken, was nur wegen dieser mythischen "rückwärtskompatibilität" so merkwürdig umgesetzt wurde. Ich kann das nicht nachvollziehen. Alle laden sich jeden monat neue versionen von eclipse runter, kaufen sich jedes halbe jahr neue computerspiele, kaufen sich alle paar jahre neue rechner, und trotzdem nahmen die java designer die finstersten hacks in kauf, um die generics doch noch irgendwie rückwärtskompatibel hinzufummeln... ???:L

Seid mir bitte nicht böse. Ist womöglich nur vorübergehende Stimmungsschwankung, vielleicht sehe ich ja irgendwann mal ein, dass es wirklich irgendwie supertoll ist. Aber konkret heute hab ich mir wieder sowas durchgelesen, und will einfach nur irgendwohin kreischend wegrennen. Allerdings weiß ich nicht wohin. Wahrscheinlich finde ich nie eine Sprache, die mir 100% gefällt, bis ich mir eine eigene formuliere...^^ :roll:

greetz
Andrey

 

[SlaterB]

Arrays waren schon vor Generics immer bisschen anders, wie auch die einfachen Datentypen gegenüber ihren Wrappern (int vs Integer)

nimm Collections

 

[didjitalist]

kann SlaterB nur zustimmen. wenn man mit generics arbeitet, sollte man array vergessen. alle collection klassen lassen sich auch immutable machen, man vermisst also nix.

 

[0x7F800000]

Hm, ja, solange ich die ganzen vorgefertigten Datenstrukturen mit Generics anwende, habe ich auch keine probleme damit, habe mich noch nie durch die merkwürdigen eigenschaften von generics eingeschränkt gefühlt, wenn's um die normale anwendung ging.

Aber jedes mal, wenn ich selbst irgendeinen lowleveligen sortieralgorithmus auf arrays mit unbekannten inhalt loslassen wollte, ging wie immer gar nichts mehr. :roll:
Und wenn es eine implementierung "zu lehrzwecken" sein soll, an der nachvollziehbar bleiben sollte, was da passiert, sind solche monströse reflection-api konstruktionen irgendwie fehl am platz.

Es ist ja auch nicht so, als ob Java darunter irgendwie zu leiden hätte. In 99,99% der fälle störts ja keinen. Aber wenn man dann ein bisschen genauer hinschaut, dann stellt man doch fest, dass diese umsetzung von generics irgendwie ziemlich... hässlich ist :roll: Ich kann mir jedenfalls nicht vorstellen, dass sich das irgendein Mensch auch noch in 20 jahren anguggt, und so schön findet, dass er das gar nicht ändern will und einfach weiter so lässt wie es ist.

Das mit der Rückwärtskompatibilität ist doch ein allgemeines Problem:
- Auf dauer überleben eh nur die besten (Bakterien, Ratten, Viren, Algorithmen, Religionen, Autos, ..., Programmiersprachen)
- Generics finde ich in Java nicht so toll gelungen. Meine meinung zählt einen Dreck, okay... Aber eines tages wird doch womöglich einer kommen, der dasselbe meint, und dessen Wort was zählt. Also wird Java entweder abgeändert oder abgeschafft.
- Je später das passiert, desto mehr vorwärtsinkompatiblen code gibt es bis dahin, und das ist dann umso schwieriger, alles wieder gradezubiegen.

Warum verscheibt also überhaupt jemand veränderungen auf später, statt mängel so früh wie nur möglich loszuwerden? Wozu überhaupt Rückwärtskompatibilität, ewig kann's doch eh nicht gutgehen? :bahnhof: