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. :shock:

Delphi-Quellcode:

try

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

und sowas geht auch nicht. :cry:

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. :oops: :thumb:
Jetzt wo du es sagst, dort hatte ich mir schonmal sowas wie beim on-do gewünscht (Inline-Variable :wall:).
z.B.

Delphi-Quellcode:

with e := ... do ...

statt

Delphi-Quellcode:

with xxx do ...

und jetzt

Delphi-Quellcode:

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.

[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/

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1465567)

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:

Zitat von Harry Stahl (Beitrag 1465570)

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.

[Uwe Raabe]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1465568)

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1465573)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1465568)

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.:mrgreen:

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1465578)

Das ist doch die Argumentation der ewiggestrigen,

:o 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.

[p80286]

Du hast mich zu ernst genommen. Ist halt kein Killerfeature.

Gruß
K-H