10.4 : Warum Inline-Variablen?

[himitsu]

Moin,

ich weiß ja dass Viele es sich wünschten und es in anderen viel cooleren Sprachen sowas schon lange gibt,
aber wieso musste man sowas auch unbedingt ins Pascal einbauen?

Man soll doch Funktionen eh so klein wie möglich machen und alles schön viel aufteilen,
da gibt es doch eigentlich keinen Grund seine Variablen nicht übersichtlich an den drei alt bekannten Stellen zu sammeln. Hier also Lokal vor's BEGIN.



OK, ich musste erstmal ausprobieren, aber es geht wirklich und es ist für mich aktuell die einzige Stelle, wo es schon ganz nett sein könnte.

Delphi-Quellcode:

for var I := 0 to 3 do 
  ...

// oder
for var i in [0..3] do  // mit einem Enum sieht es noch besser aus
  ...

Aber die andere Stelle, wo es von der neuen Syntax her viel Sinn ergeben würde, da darf man es nicht machen, um diese Variable endlich mal richtig zu kennzeichnen.

Delphi-Quellcode:

try

except
  on var E: Exception do
    ...
end;

und sowas geht auch nicht.

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  var i: Integer = 2;  // EDIT: das hier geht, wenn man := verwendet, aber es weicht doch zu sehr von der Konstantensyntax ab
  if var x := i + 3 then
    if x = 5 then juhuuu;
end;

Variablen im IF umzuschreiben ist doch das Beste, was es jemals gab.
Ich kann mich noch gut an den Spaß erinnern, wo ich im PHP statt einen == nur ein = machte und dann Stunden freudig juchzend gesucht hatte, warum sich der Wert einer Variable ändert.

[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