Oh Mann. Was ich für meine Diplomarbeit programmiere, darf ich entweder
in PL/SQL oder in Java machen (obwohl, heute hat $CHEF auch C fallen
lassen, aber das kann ich nun gar nicht). Gut, die Entscheidung war
einfach, aber glücklich werde ich damit wohl auch nicht.
Offenbar hat die Zeit, in der ich Java nicht mehr anfassen mußte
gereicht, mich so einige Dinge vergessen zu lassen. Und zwischendurch
habe ich Dinge gelernt, von denen ich "damals" noch gar nichts wußte. Es
ist ja schon idiotisch, dass ich tatsächlich jeden Scheiß in eine Klasse
stecken muß. Aber diese statische Typisierung macht mich total fertig.
Ich brauchte zum Beispiel eine Funkt^WMethode, die von drei
Elementen das kleinste zurückgibt. Math.min in seinen verschiedenen
Inkarnationen (für int/Integer, double etc.) nimmt aber nur jeweils
zwei Elemente an. Schachteln wäre eine Möglichkeit gewesen, ging aber
gegen meinen Stolz. Gut, dachte ich: guckst Du mal im
Collection-Interface nach, ob es da sowas gibt. Natürlich gibt es
sowas nicht, denn dann müßte die Collection ja sicherstellen, daß jedes
Element auch das Interface Comparable implementiert. Also fange ich an
eine Methode zu schreiben. die eine Collection mit Comparables annimmt
und ein Comparable zurückgibt (Java 5.0 sei Dank geht das ja ohne
Casten). Das klappt aber auch nicht, weil ich mit dem Comparable später
rechnen will und der Compiler sich nicht sicher ist, dass das geht. Muß
ich also doch casten. Eine andere Überlegung war, einfach die
Vergleichsfunkti^H^H^H^H^H^Hmethode per Parameter zu übergeben.
Geht ja aber auch nicht, weil Methoden in Java keine Objekte sind. Das
gleiche Problem fünf Minuten später. Ich hatte mich entschieden, eine
weitere Methode static zu machen. Danach maulte Eclipse mich an, dass
ich this im Kontext einer statischen Methode nicht benutzen dürfte.
Ich frag mich wieso, this könnte dann doch einfach auf die aktuelle
Klasse zeigen. Aber ne, Klassen sind ja auch keine Objekte...
Ach, und die Klasse String ist aus mir unbekannten Gründen als final
gekennzeichnet. Tolle Wurst. Was ich mache, wäre nämlich am besten in
einer Unterklasse von String aufgehoben. Aber ich kann natürlich auch
die tausendste StringWrapper selbst implementieren, bitte sehr, gern
geschehen.
Sicher, es ist immer etwas schwierig, sich auf ein neues/ungewohntes Paradigma einzustellen. Und diese statische Typisierung hat bestimmt auch irgendwelche Vorteile, die mir grad nicht einfallen. Mir ist aber heute so richtig klargeworden, wie sehr man in solchen Sprachen damit beschäftigt ist, nur den Compiler zufriedenzustellen, obwohl man doch genau weiß, was man tut. Bevormundung durch Technik. Nix für Leute mit Stolz. :->