Gefährliche neue Sprachfunktionen: Indizierungszugriffssyntax für Listen und Karten

In diesem Blog spreche ich über ein neues Sprachfeature, das von project coin für Java7 vorgeschlagen wurde, und über die Probleme, die ich damit sehe. Vielleicht ist es an der Zeit, sich die Scala-Bücher zu kaufen und tief in die Materie einzutauchen...

Wer hat dieses Konstrukt schon einmal gesehen?

  int i, j;
  i = j = 10;

Lässt sich das überhaupt kompilieren? Natürlich wird es das: Der Wert einer Zuweisung ist die rechte Seite der Zuweisung und kann daher einer anderen Variablen zugewiesen werden. In meiner beruflichen Laufbahn sind mir solche Anweisungen bisher nur in Frameworks begegnet, die von Leuten geschrieben wurden, die zu schlau für ihr eigenes Wohl sind. Es dauert ein paar Sekunden, bis man es kapiert hat, und dann wird einem klar, dass beide Variablen auf denselben Wert gesetzt werden, kein Problem! Ich sehe den Wert dieses "Features" der Java-Sprache nicht: Die Aufteilung auf zwei Zeilen schadet weder dem Compiler noch der JVM und schon gar nicht dem armen Programmierer, der die Codezeilen lesen muss, nachdem das Genie, das sie ursprünglich geschrieben hat, das Gebäude verlassen hat. Kürzlich habe ich einen Vorschlag für ein neues Feature in Jdk7 gelesen, das Indexierungszugriff für Listen und Maps bieten wird. Die normalen Beispiele sind recht einfach zu lesen oder zu schreiben:

  Liste Namen = ...
  names[0] = "Maarten Winkels"; // - ->  names.set(0, "Maarten Winkels");
  String you = names[1]; // -.>  names.get(1);
  Karte Wohnort = ...
  Wohnort["Maarten Winkels"] = "Indien"; // ->  Wohnort.put("Maarten Winkels", "Indien");
  String r = residence["Koningin Beatrix"]; // - ->  residence.get("Koningin Beatrix");

Das sieht auf den ersten Blick gut aus. Der Code ist jedoch kürzer und leichter zu lesen, während viele gute Dinge wie Typsicherheit (die Liste ist immer noch eine Liste) und Polymorphismus (die Indexoperatoren sind auf den Java-Kernschnittstellen definiert und funktionieren in jeder Implementierung) beibehalten werden. Als ich das fortgeschrittenere Beispiel las, begann sich etwas in meinem Kopf zu regen.

  residence["Maarten Winkels"] = residence["Koningin Beatrix"] = "Palace";

Was sagt Ihnen also diese Codezeile? Vielleicht müssen Sie sie sich noch einmal ansehen, bevor Sie Ihre Antwort geben. Zunächst könnten Sie zu dem Schluss kommen, dass die Königin ("=Koningin") und ich uns einen Palast teilen werden. Das ist doch das, was die normale "doppelte" Zuordnung bedeutet, oder? Beide Variablen werden den gleichen Wert haben. Denken Sie um! Die Königin wird in einen Palast umziehen und ich bleibe an dem Ort, an dem sie vorher gewohnt hat (was vielleicht immer noch in Ordnung ist...)! Der Grund dafür ist, dass die Put-Operation auf einer Map tatsächlich den zuvor gespeicherten Wert zurückgibt. Der Code lässt sich wie folgt übersetzen:

  residence.put("Maarten Winkels", residence.put("Koningin Beatrix", "Palace"));

Damit sollte klar sein, dass ich einen anderen Wohnsitz habe als die Königin. Wenn der Königin in der Karte kein Wert zugeordnet ist, gibt put null zurück und ich könnte sogar obdachlos sein!Ich halte dies für eine sehr schlechte Funktion. Man könnte argumentieren, dass die Funktion der "doppelten" Zuweisung nicht sehr oft verwendet wird, aber ich bin der Meinung, dass eine Sprache für den Leser so konsistent wie möglich sein sollte, und dies weicht meiner Meinung nach eindeutig von diesem Weg ab. Wie können wir dieses Problem lösen und gleichzeitig die Konsistenz und Abwärtskompatibilität aufrechterhalten? Ich denke, das ist wirklich schwierig: Wir könnten den Zuweisungsoperator aus dem Vorschlag dazu bringen, keinen Wert zurückzugeben (und stattdessen void zurückzugeben, so dass eine "doppelte" Zuweisung unmöglich ist. Dies wäre jedoch nicht mit einem normalen Zuweisungsoperator vereinbar. Sollte dieser Vorbehalt verhindern, dass diese ansonsten schöne neue Funktion in die Java-Sprache aufgenommen wird? Ich denke, wir sollten uns genau ansehen, was wir mit Java7 erreichen wollen. Für mich wäre es wichtiger, Java-Entwickler in die Lage zu versetzen, bestehende Codebasen einfach zu lesen und zu korrigieren. Wenn sie ein paar Zeichen einsparen können, ist das in Ordnung, aber die allgemeine Verständlichkeit der Sprache und die Möglichkeit, häufige Fehler mit neuen Konstrukten zu beheben (z.B. die Verwendung von Closures zur Einsparung von Ressourcen) ist viel wichtiger. Java (die Sprache) sollte keine Funktionen hinzufügen, nur um den LoC eines Programms auf das Niveau von Groovy oder Ruby zu bringen: Bei einer großen Anwendung sind das sehr kurzfristige Ziele. Es gibt ohnehin viele Möglichkeiten, diese Sprachen auf der JVM zu integrieren. Warum also sollte die Sprache Java mit ihnen konkurrieren?