Re: Eklige Vergleiche von Referenzen mittels ==

"Ingo R. Homann" skribis:

Das Problem ist, dass es schöner gewesen wäre, hätte sun von vorneherein
die Langspec in etwa so definiert:

1. Auf Primitiven wird zum Vergleich == verwendet.
2. Bei Objekten wird, wenn im Programmtext == steht, die equals-Methode
aufgerufen (und meinetwegen analog für <,>,<=,>= die compareTo-Methode).
3. Für Referenzen gibt es zusätzlich den Operator ===, der Referenzen
auf Identität vergleicht.

Das wäre eine Möglichkeit.

Soll heissen: Das eigentlich unschöne an Java ist (zumindest an dieser
Stelle), dass == je nach Variablen-Typ (Primitive/Objekt-Referenz) ein
andere Semantik (*) hat.

Die andere Möglichkeit wäre diese:

(*) Für Klugscheisser: Mir ist klar, dass man sich Semantiken definieren
kann, so dass == für beide Variablen-Typen die gleiche Semantik hat,
indem man z.B. sagt, dass Primitive nun mal 'konstante Entitäten' sind,
die daher nicht auf 'semantische Gleichheit', sondern auf 'Identität'
überprüft werden können und so weiter. Aber aus Programmierer-Sicht ist
das *keine* intuitive Definition einer Semantik, wie die Existenz dieses
Threads blendend beweist.

(Dazu hätte IMHO auch gehört, dass primitive Typen Methoden haben
können, mindestens die Standard-Methoden von Object, dazu vielleicht
noch Comparable (außer bei Boolean) u.ä. Das muss ja nicht die VM
unterstützen, das kann der Compiler simulieren.)

Tja, wenn das wenigstens durchgezogen worden wäre. Das Problem ist ja,
dass ==, wenn man einen int- mit einem long-Wert vergleicht, eine
implizite Umwandlung macht - und zwar nicht nur des Typs, sondern
auch des Wertes, so dass 42L == 42 immer wahr ist, wogegen etwa
nicht einmal new Long(42).equals(new Integer(42)) gilt (geschweige
denn ==).

Und durch das Autoboxing wird dann auch noch die Grenze zwischen
den beiden Typen-Sorten verwischt.
Das ist das eigentliche Problem.


Paul
--
Zitieren im Usenet: http://einklich.net/usenet/zitier.htm
Warum Realnamen: http://www.wschmidhuber.de/realname/
.