Re: Eklige Vergleiche von Referenzen mittels ==

Hi,

Paul Ebermann schrieb:
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:

Eigentlich meinte ich nicht Dich damit, Paul! ;-)

>>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.

Wie gesagt: Das wäre natürlich eine "konsistente" Lösung gewesen, aber intuitiv wäre sie nicht. Und damit würde sie das Kern-Problem nicht lösen.

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 ==).

Guter Hinweis, den ich in dem Moment nicht bedacht hatte! Die Frage ist, ob man eine 'sinnvolle' Implementierung von Integer./Long.equals hinbekommen würde, die ein intuitives und konsistentes Verhalten sicherstellt. Notfalls ginge das nicht allein über die API, sondern nur über JVM-Interna. Andererseits wäre es ohne das Vorhandensein von den Primitiven int/long sowieso schwierig, eine Klasse Integer bzw. Long zu implementieren! ;-)

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

IMHO wäre das wieder nur ein Folgeproblem, welches das *eigentliche* Problem, welches ich oben genannt habe (== vs ===), verschärft.

Ciao,
Ingo

.