Den Rückgabetype musst du nicht benutzen. Alle Argumente müssen hingegen vorhanden sein. (Auch wenn sie null sind und das null noch gecastet werden muss)
Danke für die Antwort. Meine Frage ist jedoch WARUM lässt man das nicht zu? Eine Unterscheidung zweier Methoden über den Rückgabetyp wäre doch theoretisch möglich, oder nicht?
Hmm, obwohl eine Methode die nen Rückgabewert hat aufzurufen und diesen zu nutzen ist wirklich ein bischen sinnlos. Falls man also ein int in einem Fall und ein void in dem anderen hätte könnte man das schon unterscheiden, aber nur wenn man halt ne Zuweisung macht. Da aber auch der Fall ohne Zuweisung gültig ist wären wir ja wieder beim o.g. Problem, da kann man es ja nicht unterscheiden
Das frage ich mich, seitdem es Java gibt. Bei Ada95 gehört der Rückgabewert beispielsweise zur Signatur, und ich finde das fürs Überladen wirklich praktisch. In Java hilft hingegen nur, entweder andere Parameter oder andere Namen zu verwenden. Zwar ist das nicht schön, aber es ist machbar.
Der einzige sinnvolle Grund, der mir einfällt, ist, daß der Bau von Übersetzern vereinfacht wird. So ganz bin ich mit der Antwort jedoch selbst nicht zufrieden.
Nur weil ich den Rückgabewert nicht benötige (= irgendwo weitergebe), heisst das noch lange nicht, dass ich nicht die Methode mit Rückgabewert int aufrufen will. Es ist sinnvoll, dass dies nicht geht.
Nur weil ich den Rückgabewert nicht benötige (= irgendwo weitergebe), heisst das noch lange nicht, dass ich nicht die Methode mit Rückgabewert int aufrufen will. Es ist sinnvoll, dass dies nicht geht.
publicclassCrystalMethTest{publicstaticvoidmain(String[] args){add(1);}staticvoidadd(int i){// mach was mit i}staticintadd(int i){// mach was mit iif(fehler)return fehler;return keinFehler;}}
In diesem Beispiel wäre es theoretisch möglich, dass beide Methoden aufgerufen werden (wenn der Rückgabewert der Methoden zur Signatur gehören würden). Woher soll der Compiler wissen, welche Methode gemeint ist?
Er könnte es nur dass wissen, wenn man den Rückgabewert einer Methode zwingend verarbeiten müsste, was man aber nicht muss. Er wäre auch Blödsinn, das zu müssen, da ja auch Werte zurückgegeben werden könnten, die u.U. nicht relevant sind - man müsste in dem Fall lauter unnötige Temporärvariablen erzeugen.
Wortraum hat gesagt.:
Der einzige sinnvolle Grund, der mir einfällt, ist, daß der Bau von Übersetzern vereinfacht wird.
Die Syntaxerkennung ist das kleinste Problem beim Bau eines Compilers und da die Rückgabewerte sowieso erkannt werden müssen, ist es nicht mal ein großer Mehraufwand auch noch darauf zu achten welche Methode jetzt aufgerufen wird.
> da ja auch Werte zurückgegeben werden könnten, die u.U. nicht relevant sind
Warum sollte man aber eine Methode aufrufen die was zurückgibt, wenn der Rückgabewert für mich irrelevant ist? Dann hätte ich mir den Aufruf ja gleich sparen können.
Warum sollte man aber eine Methode aufrufen die was zurückgibt, wenn der Rückgabewert für mich irrelevant ist? Dann hätte ich mir den Aufruf ja gleich sparen können.
In reinen funktionalen Programmiersprachen wie Haskell wäre diese Aussage korrekt. Dort hat eine Funktion keine Seiteneffekte. In objektorientierten Sprachen ist das aber falsch. Da kann etwas zurückgegeben werden (Beispiele gibts ja schon im Thread) und nebenbei wurde die Festplatte gelöscht. Da kann der Rückgabewert also evtl. auch ignoriert werden.
Sagen wir, folgendes (in diesem Kontext vielleicht nicht gerade logisches) Beispiel:
Java:
publicclassTest{publicstaticvoidmain(String... args){saveValue(8);}privatestaticdouble val;staticintsaveValue(int val){Test.val = val * val;return(int)Test.val;}staticdoublesaveValue(int val){Test.val =Math.sqrt(val);returnTest.val;}}
Was soll nun aufgerufen werden? Wie wir wissen kann void gegen etwas anderes als Beispiel ignoriert werden, da ein Rückgabewert nicht verwendet werden muss.
Um die Frage, warum der Rückgabewert nicht zur Signatur gehört, geht es ja gerade. Wie schon gesagt, ist es schwieriger, einen Übersetzer zu schreiben, und es stellt sich die Frage, ob es eine sinnvolle Funktion ist. Zugegeben, sie ist praktisch, aber sie ist nicht notwendig.
Was passiert, wenn ein Aufruf nicht eindeutig ist, ist in Java natürlich nicht definiert, weil der Rückgabewert dort nicht zur Signatur gehört. Es wäre jedoch kein Problem, Aufrufe, die nicht eindeutig sind, zu verbieten, oder eine Syntax wie double'getValue() einzuführen.
Bei Java entschieden sich die Entwickler dagegen, den Rückgabewert mit in die Signatur zu packen. Es macht die Sprache einfacher. Auch das Überladen von Operatoren ist nicht möglich; es macht die Sprache einfacher. Viel mehr gibt es dazu, denke ich, nicht zu sagen.
> Keine Seiteneffekte...
>Da kann der Rückgabewert also evtl. auch ignoriert werden.
Ergo, weil ne Methode nicht unbedingt nur ein Ergebnis erzeugt was mich immer interessieren müsste sondern auch noch andere Sachen machen kann, ohne das ich den Rückgabewert brauche, ist es manchmal sinnvoll den Rückgabewert zu ignorieren?
Hmm, in diesem Zusammenhang kann mir evtl. jemand auch nochmal vom müden Joe erklären. Wieso kann ich bei Array den Rückgabewert ignorieren? Seiteneffekt wäre es wird was hinzugefügt? Und boolean sagt mir obs geklappt hat oder nicht. Oder wie seh ich das? Wärs nicht immer interessant zu prüfen ob das add funktioniert hat?
