Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
2. Bonus-Aufgabe: Even Fun(nier)
Ich hätte eine Frage bzgl. dessen was man eigentlich genau darf und was nicht. Normalerweise durften wir bisher beliebige private Felder und Methoden hinzufügen ohne bestehende Signaturen zu verändern, aber dieses Mal haben wir ja eine explizite FunFun-Dokumentation vorgegeben. Ich komme allerdings um einen weiteren nicht verlangten Konstruktor irgendwie nicht drumherum.
Die Tests laufen zwar alle schön durch aber ich muss gestehen, dass mich noch keine Aufgabe so sehr verwirrt hat wie diese generischen Typen und leckere Curry Funktionen. Man schlägt hauptsächlich so lange auf Eclipse ein bis diese rotunterstrichenen Passagen endlich verschwunden sind 
Es geht auf alle Fälle ohne Ergänzungen von Konstruktoren.
Was hast du als Übergabeparameter im FunList-Konstruktor (es soll E[] es sein) und was passiert bei dir genau, wenn du nur einen Konstruktor a la Dokumentation entwirfst (vermutlich entsteht da irgendwo ein Compilerfehler bei der for each - Schleife)?
Es geht eigentlich um die Methoden, die eine Kopie bzw. eine “neue” FunList zurückgeben sollen. Da der Konstruktor, wie du schon angesprochen hast, eben so ein generisches Array E[] erwartet, man aber keines zur Laufzeit erstellen kann, hab ich mir noch einen geschrieben der einfach eine ArrayList entgegennimmt.
Hmm, ich war nochmal googlen und hab diesmal einen interessanten Ansatz gefunden:
http://stackoverflow.com/questions/529085/how-to-generic-array-creation
Scheinbar wäre es auf diese Art möglich. Dann wäre natürlich meine Frage, ob ich das jetzt in meinem Code entsprechend ändern sollte, oder ob ich meinen zweiten Konstruktor so beibelassen kann.
Da eine Dokumentation auch nur die Schnittstelle nach außen beschreibt, sollte eigentlich nichts gegen einen privaten Konstruktor sprechen.
Aber versteh ich das richtig, dass dein Problem ist, dass du eine ArrayList hast, aber ein Array E[] brauchst? Schau mal in die Java API. ^^
lol 
Ja manchmal sieht man den Wald vor lauter Bäumen nicht und vielleicht sollte ich nicht immer nachts um 4 an den Aufgaben hocken. Aber da haben wir eigentlich wieder das, was ich von Anfang an nicht ganz verstanden habe. Könnte mir evtl. kurz erklären worin eigentlich der Unterschied der Rückgabewerte bei folgen Methoden liegt?
public FunList map(…)
public FunList filter(…)
Was genau bewirkt das explizite Angeben des generischen Typs beim Rückgabewert von map()? Macht das wirklich einen Unterschied?
FunList ist selber ein generischer Typ mit Typparameter E. Die filter-Methode ist definiert, eine neue FunList mit demselben Typparameter wie die urspruengliche Liste zurueckzugeben (wenn also eine Liste mit Integer-Objekten gefiltert wird, kommt wieder eine Liste mit Integer-Objekten raus).
Anders schaut es bei der map-Methode aus: dort wird eine FunList mit E-Objekten auf eine FunList mit R-Objekten abgebildet („gemappt“). Da „R“ nirgends definiert wurde, wird mit „“ definiert, dass es sich dabei um einen Typparameter handelt. Deshalb ist die Angabe des Typparameters im Falle der map() unbedingt noetig.
Vielen Dank! So langsam macht das Ganze für mich sogar richtig Sinn 
Hallo!
Ich habe die Aufgabe jetzt auch soweit bearbeitet und der Test mit Hilfe von “FunFun.java” verläuft auch erfolgreich (also ohne Assert-Error).
Beim Hochladen bekomme ich aber lediglich ein Ausrufezeichen.
Kann es daran liegen, dass ich Warnungen wie “Type safety: Unchecked cast from Object[] to E[]” bekomme?
Allerdings weiß ich spontan nicht, wie ich es sonst lösen sollte.
Gruß
try {
1.) Hast du FunFun auch wirklich mit aktiviertem assertion-checking (also mit java -ea FunFun) ausgeführt?
2.) Hast du eine „frische FunFun“ verwendet? Nachdem hier viele offenbar Eclipse als Code-Generator und -Korrektor („Strg-1/Enter“) nutzen, sei gewarnt: Manche Refactorings von Eclipse verändern womöglich die Vorgabe, um den „vermeintlichen Fehler“ zu beheben, anstatt den eigenen Code anzupassen!! => Vorgabe (hier insbesondere: FunFun.java, aber auch die anderen Klassen) frisch von der Homepage laden, alles zusammen nochmal übersetzen und mit -ea ausführen!
}
Warnungen sollten kein Problem sein.
Es geht aber auch ohne: Wozu verwendest du überhaupt irgendwo ein „Object“?? Programmiere lieber von grund auf type-safe (soweit es in Java geht…)!
Vielen Dank!
Mir hat Eclipse wirklich einen Streich gespielt…
Das mache ich, da man kein Array vom Typen „E“ erstellen kann:
„Error - Cannot create a generic array of E“.
Wir sollen ja z.B. bei der Methode „tail“ oder „filter“ eine neue (Instanz von) FunList zurückgeben.
Der (vorgegebene) Konstruktor nimmer aber nur ein Array vom generischen Typen E an.
Um dies zu realisieren erstelle ich mir in diesen Methoden eine ArrayList und übergebe dem Konstruktor von FunList dann das Ergebnis der Methode „toArray“ der ArrayList und caste dieses per (E).
gerne 
this:
… der könnte dann z.B. eine ArrayList entgegennehmen, die vorher oder nachher ge-clone()-d wird
Oh weh… manchmal stelle mich echt doof an.
Vielen Dank. Jetzt ist mir alles klar und es geht wirklich ohne Warnungen 
Sind die Testcases im EST anders als die FunFun.java - Cases?
Ich bekomme nämlich ein rotes Kreuz im EST, obwohl die (unveränderte) FunFun bei mir problemlos mit -ea durchläuft…
Benutze auch einen einfachen Editor, kein Eclipse oder so.
Jein - es sind wesentlich MEHR Testfälle (derzeit ca. 144 insgesamt, davon 89 „zusätzliche“, die es so in der FunFun nicht gibt).
In deinem Fall würde ich mir die mitgelieferte API nochmal sehr genau anschauen und die Sichtbarkeiten der Konstruktoren prüfen - oder zusätzliche Testfälle selber ergänzen, die auch „extreme Grenzfälle“ abprüfen…
[quote=JohnDoe:1389355038]
und die Sichtbarkeiten der Konstruktoren prüfen[/quote]
Danke, genau das war es bei mir. In dem Moment fiel mir auch noch der Hinweis vom ersten(?) Blatt ein, dass man das doch bitte immer so machen soll. Ups