@Override rockt nicht
-
Ist zwar eine nette Idee, aber solange man nicht verpflichtet ist, es hinzuschreiben, ist es kein gescheiter Schutz.
Gut, wenn man immer dran denkt, es hinzuschreiben, dann kriegt man einen Fehler, wenn die Methode nichts overridet. Aber erstens kann man das vergessen und das stört dann den Compiler nicht und zweitens ist es damit kein Schutz gegen aus-Versehen-was-overriden.Besonders traurig finde ich es, wenn ich in Derived extends Base explizit was override und in Derived2 extends Derived immer noch nicht verpflichtet bin, explizit overriden zu kennzeichnen.
Was meint ihr dazu?
-
Rockt final auch nicht, weil man es vergessen kann?
...natürlich rockt @Override.
-
final und override sind zwei verschiedene Paar Stiefel.
Und ich finde es generell schlecht, wenn man etwas vergessen kann. Damit ist @Override zwar nicht gleich schlecht, aber man hätte auch weiter gehen können und es zur Pflicht machen können. Dann hätte es gerockt, aber so ist es nur nice to have und letztlich nichts, worauf man sich verlassen kann.Das ist doch der Punkt. Es ist nicht verlässlich. Ich kann aus Versehen ne Methode redefinieren, weil ich übersehe, dass es 10 Ebenen höher schon mal so eine gibt.
Du wirst mir jetzt gleich sagen, dass der alte Sourcecode nicht mehr compiliert werden könnte. Das ist auch sicherlich richtig, aber das macht @Override noch lange nicht zum Rocker, so wie es jetzt ist.
-
Optimizer schrieb:
Du wirst mir jetzt gleich sagen, dass der alte Sourcecode nicht mehr compiliert werden könnte.
Stimmt. Genau das wollte ich dir gerade sagen. Bei Java wird ne ganze Menge Rücksicht auf alten Code genommen. Ob man das nun gut heißt oder nicht, ist egal: Es ist nunmal so und man kann die Sprache nicht beliebig verändern. Da muss man auch mal Kompromisse eingehen. Wenn ein Feature nun nicht zur Pflicht wird oder nicht alles leistet, was ein Feature in der Art leisten könnte, dann muss man das halt akzeptieren. Es ist trotzdem besser, dass es jetzt da ist und wenn man es sich angewöhnt, dann vergißt man es auch nicht.
Gut, man könnte noch Compilerwarnungen ausgeben, wenn ein Override fehlt. Mach doch so einen RFE.
-
...wobei entsprechende Warnungen wohl auf Dauer eh in die IDEs integriert werden.
-
... und irgendwann endet Java dann so wie C++. Unmengen an möglichkeiten, viele aber nicht richtig umgesetzt, da ja auf Kompatibilität geachtet werden musste. Traurig, traurig.
-
Helium schrieb:
... und irgendwann endet Java dann so wie C++. Unmengen an möglichkeiten, viele aber nicht richtig umgesetzt, da ja auf Kompatibilität geachtet werden musste. Traurig, traurig.
In 10 Jahren ist sicherlich wieder ne neue Sprache aktuell, in der die Fehler von Java nicht gemacht werden, sondern irgendwelche anderen, die dazu führen, dass in 30 Jahren wieder ne andere Sprache aktuell ist. So ist das nunmal. Man kann eine Sprache nicht beliebig verändern, auch wenn das wünschenswert wäre.
-
Helium schrieb:
... und irgendwann endet Java dann so wie C++. Unmengen an möglichkeiten, viele aber nicht richtig umgesetzt, da ja auf Kompatibilität geachtet werden musste. Traurig, traurig.
Glaubst du?! Java ist schließlich nur zu einem bestimmten Grad abwärtskompatibel.
Liebe Grüße
Real
-
IMHO kannst du heute noch Java 1.0 Source mit dem 1.5er JDK compilieren. Das hat unbestreitbar schon auch seine Vorteile.