10.4 : Warum Inline-Variablen?

[jaenicke]

Inline Variablen sind so ähnlich wie with:
Erleichtert das Schreiben von Code, verringert die Lesbarkeit und Wartbarkeit aber deutlich.

Immerhin hat es weniger negative Auswirkungen als with. Wenn aber der Rückgabewert einer Methode sich ändert, ändert sich ohne Typangabe auch plötzlich der Typ. Und dann kommt an ganz anderer Stelle ein Fehler.

Ich finde außerdem, dass es den Quelltext schlechter lesbar macht.

Aber wie so vieles (Quelltextformatierung, ...) ist es eben Geschmackssache. Ich persönlich werde das Feature sicher sehr spärlich verwenden... außer bei Schleifen, wo es durchaus praktisch ist, dass die Variable danach nicht mehr verfügbar ist. Das muss jeder für sich selbst entscheiden.

[himitsu]

Ohhhhhhh, stimmt ja, das blöde WITH, ganz vergessen.
Jetzt wo du es sagst, dort hatte ich mir schonmal sowas wie beim on-do gewünscht (Inline-Variable ).
z.B. with e := ... do ... statt with xxx do ... und jetzt begin var E := xxx; .... end; , also eigentlich das Gleiche/Selbe, nur mit 'ner anderen Syntax.

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein besserer Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

[jaenicke]

Zitat von himitsu:

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein schöner Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

Dann aber mit begin..end drum herum...

Delphi-Quellcode:

procedure TForm71.FormCreate(Sender: TObject);
begin
  begin
    var a := 42;
    ShowMessage(IntToStr(a));
  end;
  a := 33; // hier gibt es die Variable nicht mehr --> Fehler
end;

Auf die Weise kann man Interfaces z.B. wieder aus dem Scope laufen lassen.

Es gibt schon durchaus Stellen, an denen es Sinn macht so etwas zu verwenden. Darum sage ich ja auch, dass ich persönlich es nicht möchte. Aber ich verstehe durchaus, wenn das jemand anders sieht.

Zitat von Harry Stahl:

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

[Harry Stahl]

Zitat von Harry Stahl:

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

Zitat von jaenicke:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

Erfreulicherweise läßt Delphi Dir die Wahl.

Statt
var files := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');
kanst Du auch

var files : TStringDynArray := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');
schreiben...

[DieDolly]

Zitat von jaenicke:

Zitat von himitsu:

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein schöner Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

Dann aber mit begin..end drum herum...

Delphi-Quellcode:

procedure TForm71.FormCreate(Sender: TObject);
begin
  begin
    var a := 42;
    ShowMessage(IntToStr(a));
  end;
  a := 33; // hier gibt es die Variable nicht mehr --> Fehler
end;

Auf die Weise kann man Interfaces z.B. wieder aus dem Scope laufen lassen.

Es gibt schon durchaus Stellen, an denen es Sinn macht so etwas zu verwenden. Darum sage ich ja auch, dass ich persönlich es nicht möchte. Aber ich verstehe durchaus, wenn das jemand anders sieht.

Zitat von Harry Stahl:

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

Ist aber umständlich mit begin und end. Wenn dann doch besser mit let statt var, so wie es in JavaScript ist.

[Papaschlumpf73]

Ich kann auch gut ohne...

[Harry Stahl]

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Wer es noch ein wenig ausführlicher und mit weiteren Argumenten nachlesen möchte:

https://landgraf.dev/en/5-reasons-to...les-in-delphi/
https://www.ideasawakened.com/post/n...bles-in-delphi
https://blog.grijjy.com/2018/11/02/i...e-performance/

[Uwe Raabe]

Zitat von Papaschlumpf73:

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

[p80286]

Zitat von Uwe Raabe:

Zitat von Papaschlumpf73:

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

Das ist doch die Argumentation der ewiggestrigen, die sich jeder Neuerung sperren und die Flexibilität mit Chaos verwechseln. So bremst man den Fortschritt aus.

Gruß
K-H

[Uwe Raabe]

Zitat von p80286:

Das ist doch die Argumentation der ewiggestrigen,

das sollte es gar nicht sein!

Ich wollte damit nur hervorheben, daß das für alle neuen Features gilt. Natürlich geht es auch ohne - wie hätten wir sonst auch arbeiten können. Das wertet ein neues Feature aber nicht ab.

Eventuell muss man sich nur erst daran gewöhnen. Manchmal geht das schneller, manchmal auch nicht.