Function mit mehreren Rückgabewerten

[Dennis07]

Wäre natürlich schön, wenn Delphi nativ Tupel unterstützen würde. Python kann das sehr schön:

Code:

def give_two:
  return 1, 2

one, two = give_two()

In Delphi gibt es da nur drei möglichkeiten:

1. Du gibst ein Array oder IEnumerable-Objekt zurück
2. Du deklarierst die einen Record und gibst ihn zurück
3. Du verwendest out- (oder var-) Parameter

[freimatz]

Zitat von Dennis07:

... nur drei ...

Nein.

[Dennis07]

Zitat von freimatz:

Nein.

Bitte nicht so ausführliche Kommentare schreiben, mein Gehirn kann die nicht verarbeiten.

Zitat von Rollo62:

Delphi-Quellcode:

procedure GibMir( AInput, AOutput: string);
begin
    AOutput := AInput + '...';
end;

Du meinstest wohl out AOutput: string . Denn so macht der nen Copy-on-call und behält den zugewiesenen Wert in der Funktion. Du kannst das nur weglassen, wenn der Parameter ein Zeigertyp ist und du den Referenzwert veränderst.

[Rollo62]

Zitat von Dennis07:

Du meinstest wohl out AOutput: string .

Ja klar ...

[Sinspin]

Zitat von Dennis07:

Wäre natürlich schön, wenn Delphi nativ Tupel unterstützen würde. Python kann das sehr schön:

Code:

def give_two:
  return 1, 2

one, two = give_two()

In Delphi gibt es da nur drei möglichkeiten:

1. Du gibst ein Array oder IEnumerable-Objekt zurück
2. Du deklarierst die einen Record und gibst ihn zurück
3. Du verwendest out- (oder var-) Parameter

Wärend die Schlange nur zischt, hat das Orakel Antworten.

Ich finde Python hier unscharf und unklar.
Die Optionen die Delphi einem gibt bedeuten mehr Schreibaufwand aber auch deutlich bessere Lesbarkeit.
Gerade durch die Rückgabe oder Verwendung eines Interfaced Objektes bekommt man unendliche Freiheit. Und, das sogar ohne sich auf die Anzahl der Parameter festlegen zu müssen.
Natürlich kann sowas in Speicherverschwendung ausarten. Jede Münze hat halt zwei Seiten.

[Stevie]

Tuple unpacking ist ein ziemlich klares und verständliches Konzept.

Was an dem Code oben etwas ungewohnt ist, ist die Typinferenz bei der give_two Funktion.
Aber wenn man klareren Code schreiben will, dann kann man auch Type Hints (seit Python 3.9) und den Tuple Konstructor explizit nutzen:

Code:

def give_two() -> tuple[int,int]:
  return (1, 2)

[jaenicke]

Zitat von Stevie:

Tuple unpacking ist ein ziemlich klares und verständliches Konzept.

Verständlich ist es schon, aber wie in Delphi bei Methoden mit vielen Parametern unübersichtlich. Da finde ich benannte Argumente in C# deutlich besser. Entsprechend finde ich es auch besser, wenn man einen Record oder ähnliches zurückbekommt, so dass man mit Namen auf die Werte zugreift und nicht z.B. über Tupel basierend auf der Reihenfolge.

[Stevie]

Das ist Sache, wie Tuples implementiert werden - in C# kannst du explizite Feldnamen weglassen, oder sie definieren - siehe https://learn.microsoft.com/en-us/do...s/value-tuples
Ebenfalls in Python kannst du auch Named tuples nutzen, siehe https://www.slingacademy.com/article...uple-examples/ - das kommt eigtl schon fast an eine Deklaration eines expliziten Recordtyps heran, was wir auch in Delphi machen können.

Allerdings gehen viele Bestrebungen in modernen Programmiersprachen dahin, die sogenannte Cermony zu verringern, also diesen ganzen Boilerplate Code, den man so schreiben muss, damit der Compiler versteht, was man eigtl will. Gute Designs opfern hierbei wenig bis gar keine Verständlichkeit des Source Codes.

[jaenicke]

Zitat von Stevie:

Allerdings gehen viele Bestrebungen in modernen Programmiersprachen dahin, die sogenannte Cermony zu verringern, also diesen ganzen Boilerplate Code, den man so schreiben muss, damit der Compiler versteht, was man eigtl will.

In dem Fall geht es ja um die Lesbarkeit und Wartbarkeit für den Entwickler, nicht um etwas, das der Compiler braucht. Ich bin kein Freund davon, möglichst wenige Buchstaben zu schreiben, sondern finde gute und schnelle Lesbarkeit viel wichtiger.

[Stevie]

Zitat von jaenicke:

Zitat von Stevie:

Allerdings gehen viele Bestrebungen in modernen Programmiersprachen dahin, die sogenannte Cermony zu verringern, also diesen ganzen Boilerplate Code, den man so schreiben muss, damit der Compiler versteht, was man eigtl will.

In dem Fall geht es ja um die Lesbarkeit und Wartbarkeit für den Entwickler, nicht um etwas, das der Compiler braucht. Ich bin kein Freund davon, möglichst wenige Buchstaben zu schreiben, sondern finde gute und schnelle Lesbarkeit viel wichtiger.

Korrekt, es geht um die Essenz und nicht um den ganzen Extraklump (aka Ceremony) - gute Languagedesigner (von denen es gar nicht so viele gibt) achten darauf, dass gerade nicht die Lesbarkeit und Verständlichkeit des Codes leidet sondern verbessert wird, da man keine kognitive Leistung damit verplempert, im Kopf den ganzen Extraklump durchzuparsen. Natürlich sind bei langjährigem Gebrauch bestimmte Synapsen schon ausgetreten und so mancher meint, dass dies und das weniger lesbar oder verständlich ist. Das ist aber genauso als ob ich behaupte, dass chinesisch total schwierig und unverständlich ist, nur weil ich es nicht kann. Milliarden von Menschen würden mir da vermutlich widersprechen.

Ich führ das jetzt nicht weiter aus, weil das schon sehr offtopic ist und ich keine Lust habe, ein Essay über die Thematik zu schreiben.