Verbeserung bei Inline Variablen von 10.4 auf 11?

[fisipjm]

Moin,

mal eine Frage an alle die schon Delphi 11.0 oder sogar Delphio 11.1 einsetzen :-)
Mit der Version 10.4 wurden ja die Inline Variablen eingeführt. Ich finde die super bequem, über Sinn und Unsinn lässt sich ja ausgiebig diskutieren, aber darum soll es in diesem Post nicht gehen :wink:

Der LSP Server wurde ja dann irgendwann auch dahingehend nachgepatcht, trotzdem funktioniert die IDE nicht mehr richtig sobald ich Inline Variablen verwenden. Liebgewonnene Refactoringwerkzeuge wie "Variable deklarieren" (strg+v) oder Umbennen (shift+strg+e) funktionieren nicht mehr sobald innerhalb einer Funktion inline eine Variable deklariert wurde. Ist da in der Versionn 11.1 was passiert? Das wäre glaub ich mein letzter schups um umzustellen :-D

Guten Start in die verkürzte Woche.
Grüße
PJM

[Tristan90]

Nein, in der aktuellen Version hat sich nichts verbessert in dieser Hinsicht.

Ich bin relativ neu in der Delphi-Welt unterwegs und bin etwas schockiert, dass die Inline-Variablen so unprofessionell umgesetzt sind, dass sie eines der wichtigsten Tools in der modernen Softwareentwicklung, das Refactoring, unbrauchbar machen.

Das macht die Inline-Variablen quasi nutzlos.

[rider]

Die inline Variablen wurden bereits in 10.3 Rio eingeführt.
Die Refactoring Engine ist dagegen schon sehr alt, sie wurde mit Delphi 2005 ausgeliefert.

Vermutlich wurde diese Refactoring Engine - wie viele andere Tools - damals zugekauft
und bleibt seitdem unverändert.
Das dürfte der Grund sein, warum neue Sprachfeatures mit der Refactoring Engine nicht mehr
unterstützt werden. Tatsächlich stellt sie ihren Dienst ein, sobald inline Variablen verwendet werden.
Das ist auch mit Delphi 11.2 so.

Weiter vermute ich, dass das Refactoring komplett neu entwickelt werden müsste,
um auch neue Sprachfeatures zu unterstützen.

[TurboMagic]

Hallo,

ja, die Inline Variablen gibt's seit 10.3. Und nein, in 11.2 hat sich nicht nichts getan bezüglich Inline Variablen.
Mindestens eine Sache wurde gefixt: die Liste der Methoden oberhalb des Editors (das was früher das Castalia Add-On war, bis EMBT das aufgekauft hat).
Die Liste hatte bis 11.x nur die Methoden angezeigt, die vor der ersten Inline-Variablen Deklaration definiert/implementiert waren.
Jetzt werden alle angezeigt.

Zum Refactoring: ja, das Refactoring ist .NET basiert. Ustprünglich müsste es mal Java basiert gewesen sein und dann mittels J#, ja sowas gab's mal von MS,
integriert worden sein. Inzwischen ist es aber sicher nicht mehr J#, weil J# nicht mehr mit installiert wird, da das ja seit Zahren von Microsoft
abgekündigt ist.

Und ja, das Refactoring muss wohl mal neu auf die Beine gestellt werden. Es gibt zum Beispiel Pläne weitere der IDE Funktionen die bisher auf unterschiedlichen
Parsern basieren auf LSP umzustellen. Dadurch nutzen die den COmpiler und der ist ja bezüglich der Unterstützung der Sprache immer aktuell.

Grüße
TurboMagic

[Tristan90]

Also können wir nach fast 5 Jahren, seit Einführen der Inline-Variablen, davon ausgehen, dass in dieser Hinsicht nichts mehr passieren wird?

Ich habe nirgends eine offizielle Reaktion seitens Embarcadero gefunden.

[Der schöne Günther]

Der Erfahrung der letzten Jahre nach zu urteilen kann man sich relativ sicher sein, dass am "alten" Refactoring nichts mehr passiert. Es reicht ja auch, unter https://quality.embarcadero.com im Jira-Tracker einmal nach "refactoring" zu suchen - Das Ding ist völlig kaputt, und da wird auch ziemlich sicher nichts mehr dran gemacht.

[MyRealName]

Ich weiss nicht, ob ich es schon mal erzählt habe, aber ich damals eh ein kleines (ca. 10k Zeilen) Projekt angefangen und wollte die Inline Variablen natürlich gleich mit ausprobieren, aber irgendwann kam es zu seltsamen Fehlern, die nicht nachzuvollziehen waren. Ich habe Tagelang gesucht und probiert, refactored und und und... Als letztes habe ich alle Inline-Variablen gegen "richtige" Variablen getauscht und schon lief alles fehlerfrei.
Vielleicht geht es jetzt besser, aber das war soviel Arbeit, dass ich die Inline-Variablenm nicht mehr mit einem 3-Meter langem Stab mehr anfassen werde.

[TurboMagic]

Zitat:

Zitat von Der schöne Günther (Beitrag 1517208)

Der Erfahrung der letzten Jahre nach zu urteilen kann man sich relativ sicher sein, dass am "alten" Refactoring nichts mehr passiert. Es reicht ja auch, unter https://quality.embarcadero.com im Jira-Tracker einmal nach "refactoring" zu suchen - Das Ding ist völlig kaputt, und da wird auch ziemlich sicher nichts mehr dran gemacht.

Der Plan ist m.W. das alte Refactoring durch was anderes zu ersetzen.

[Tristan90]

Zitat:

Zitat von TurboMagic (Beitrag 1517251)

Der Plan ist m.W. das alte Refactoring durch was anderes zu ersetzen.

Klingt alles sehr vage.

[himitsu]

Zitat:

Zitat von Tristan90 (Beitrag 1518244)

Klingt alles sehr vage.

Nichts Genaues wird oft nicht mehr gesagt.

Oft genug war es dann nicht geschafft worden, drum sagt man lieber garnichts, lässt alle über den Fortschritt im Ungewissen und hat (nach deren Meinung) dann nichts zu verlieren, wenn es doch nicht (rechtzeitig) klappt.



Das "Alte" war ursprünglich garnichts richtig Eigenes
und setzt(e) auf das .NET-Framework auf.

Per se wäre es schon nett, wenn die Abhängigkeit zu .NET oder anderen extrernen Frameworks (z.B. C++Runtime) verschwinden würden (bzw. wenn die abhängige Bibliothek auf selbst mitgebrachten Fremdsachen aufsetzt),
auch wenn es oftmals eben auch aufwändiger ist, keine externen fertigen Lösungen zu nutzen.

[jaenicke]

Zitat:

Zitat von Tristan90 (Beitrag 1518244)

Zitat:

Zitat von TurboMagic (Beitrag 1517251)

Der Plan ist m.W. das alte Refactoring durch was anderes zu ersetzen.

Klingt alles sehr vage.

Der LSP-Server wäre dafür ja ideal, wenn er denn zuverlässig funktionieren würde. Bevor damit das Refactoring umgesetzt werden kann, wird die Arbeit wohl erst dort nötig sein.

[idontknow]

Hatte gerade die Hoffnung, daß mit dem neuesten 11.3 Patch vielleicht auch die Inline-Variablen nun benutzbar wären, aber nein.

Sobald ich eine Inline-Variable benutze, kann ich Shift-Strg-V zum Deklarieren von Variablen vergessen...
Nehme ich dann alle Inline-Deklarationen aus dem Code, funktioniert es sofort wieder...

Aaarrghh!

[Tristan90]

Ich sehe das mittlerweile mit (Galgen-) Humor. Immerhin kann ich auf meinem nicht vorhandenen 4K+ Monitor programmieren :thumb:

Eingeschränkt funktionierende IDE bei Verwendung von Inline Variablen, Generics, anonymen Prozeduren/Funktionen und quasi jedem Feature, das eine moderne Sprache ausmacht ABER Unterstützung für macOS Ventura, die Hauptzielgruppe von Delphi und 4K+ Monitore :lol:

[freimatz]

Ich habe drei Monitore, davon zwei 4K. Die IDE funktioniert da leidlich gut.
Inline Vaiablen - freut Euch dass ihr nur solche Probleme habt. Ich habe für mich OutputDebugString wieder entdeckt weil ich nicht Debuggen kann (keine Breakpoints) :wall:

[himitsu]

Schön, wenn der Bugfix es nicht wirklich verbessert.
https://quality.embarcadero.com/browse/RSP-23056

Nichts zu sehen war nervig, aber etwas Falsches zu sehn, ist einfach nur *****.

[skybibo]

Die Idee von Inline Variablen finde ich im Prinzip sehr gut, solange jedoch die Seiteneffekte bei der Nutzung von Inline Variablen nicht gelöst sind, verzichte ich da lieber drauf.

[himitsu]

Funktionieren tut es ja.
https://quality.embarcadero.com/browse/RSP-23056 betrifft nur die Anzeige im Debugger.

Und mein anderer Bug ist auch recht selten.
https://quality.embarcadero.com/browse/RSP-42368
Hier kommt es "auch" durch das Inline-Assembler, was hier im Zusammenhang wohl noch niemand getestet hatte.
Aber das betrifft auch nur Win32 ... Win64 kennt kein InlineAssembler mehr (nur ganze Methoden)

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1527182)

Funktionieren tut es ja.
https://quality.embarcadero.com/browse/RSP-23056 betrifft nur die Anzeige im Debugger.

Wobei ich gleiche Variablennamen trotz begrenztem Scope innerhalb der gleichen Methode ohnehin ziemlich unsauber finde.

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1527183)

Zitat:

Zitat von himitsu (Beitrag 1527182)

Funktionieren tut es ja.
https://quality.embarcadero.com/browse/RSP-23056 betrifft nur die Anzeige im Debugger.

Wobei ich gleiche Variablennamen trotz begrenztem Scope innerhalb der gleichen Methode ohnehin ziemlich unsauber finde.

Delphi-Quellcode:

for var i := 0 to 50 do begin
  MachAMit(i);
end;
// ...
for var i := 0 to 10 do begin
  MachBMit(i);
end;

finde ich jetzt nicht wirklich unsauber.

[jaenicke]

Wenn man einen Variablennamen in der gleichen Methode für verschiedene Schleifen inline verwendet, sollte man auch mit dem Namen klarmachen, wofür diese Variable verwendet wird. Durch Inline-Variablen (abgesehen von Schleifen meinetwegen) leidet (wie man an diversen Quelltexten im Internet sieht) die Lesbarkeit ohnehin schon massiv, auch weil die Methoden oft länger werden. Wenn man dann noch schauen muss, wo das i für was verwendet wird und wo es für welchen Zweck deklariert wurde, wird es noch schlimmer.

Und wenn es "nur eine Schleifenvariable ist", bei der der Name egal ist, macht es noch weniger Sinn, den gleichen Namen zu verwenden.

Ich persönlich verwende Inline-Variablen nur, wenn es einen wichtigen Grund gibt. Zum Beispiel ist es praktisch, wenn man einen Quelltext zu Debugzwecken einfügt, wenn man dann nicht zwei Teile hat, die man hinterher wieder entfernen muss.

(Der zweite Grund, weshalb viele diese einsetzen, ist, damit sie nicht zur Deklaration springen müssen. Das kann mir nicht passieren, weil meine Methoden schlicht nicht so lang sind...)

[himitsu]

Ja, ich verwnde Inline gern für FOR
und sonst möglichst nur für kurze Mehrzeiler.

Aber auch für schnelle Test-/probecodes,
sowie für Democodes.

Auch kurze DebugCodes mit einem IFDEF oder einfach nur auskommentiert, da machen sich Inline-Variablen auch ganz schön, wenn sie sich nicht mit dem normalen Code oben im VAR vermischen und man auch dort nochmal IFDEF/Auskommentieren muß, damit nicht über nichtgenutzte Variablen gemeckert wird.



Ich hatte auch die Hoffnung, dass Inline wirklich nur dann vorhanden sind, wenn sie verwendet werden.

z.B. im DECMath wollte ich bei ParameterChecks die "komplexeren" Typen nur initialisieren/finalisieren, wenn sie nötig sind, und soll der Code möglichst ohne große Operationen am Stack schnell durchrauschen.
Dann könnte man den Convertierungszweizeiler schön im IF (begin-end) haben, anstatt ihn nochmal in eine Untermethode auslagern zu müssen.

[mytbo]

Zitat:

Zitat von jaenicke (Beitrag 1527186)

Ich persönlich verwende Inline-Variablen nur, wenn es einen wichtigen Grund gibt. Zum Beispiel ist es praktisch, wenn man einen Quelltext zu Debugzwecken einfügt, wenn man dann nicht zwei Teile hat, die man hinterher wieder entfernen muss.

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen? Der Grund, warum ich im Alltag Inline-Variablen nicht verwende, ist die Kompatibilität mit älteren Delphi Versionen. Grundsätzlich finde ich sie, nach einer kurzen Eingewöhnungsphase, dosiert eingesetzt, ganz praktisch.

PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Bis bald...
Thomas

[jaenicke]

Zitat:

Zitat von mytbo (Beitrag 1527190)

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen?
[..]
PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Das ist genau der Punkt. Bei einem solchen Beispiel möchte man alles in einem Stück zeigen, da kann ich es nachvollziehen, wenn man das so macht. Ich meine schon immer Produktivcode.

In einem echten Quelltext hätte ich z.B. statt docQuery.ToUrlEncode eine Funktion GetEncodedUrl oder so verwendet und hätte daher gar keine Variable mehr benötigt.

[mytbo]

Zitat:

Zitat von jaenicke (Beitrag 1527193)

Zitat:

Zitat von mytbo (Beitrag 1527190)

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen?
[..]
PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Das ist genau der Punkt. Bei einem solchen Beispiel möchte man alles in einem Stück zeigen, da kann ich es nachvollziehen, wenn man das so macht. Ich meine schon immer Produktivcode.

Ich setze Inline-Variablen in Quelltext-Beispielen seltener ein, als ich zuerst gedacht hatte. Hier habe ich ein Beispiel gefunden. Natürlich hat auch diese Funktion ein wenig Demo-Charakter. Frage ganz konkret:

Delphi-Quellcode:

var insRowIDs: TIDDynArray;
if restClient.BatchSend(insRowIDs) = HTTP_SUCCESS then
  Result := Length(insRowIDs);

Die Variable insRowIDs wird nur an dieser Stelle verwendet. Ist das kein guter Grund, es so lokal wie möglich zu halten? Die anderen Inline-Variablen stehen gleichfalls gut zuordenbar im Kontext der Anwendung. Wenngleich mein Urteil nicht neutral ist: Ich finde den Quelltext gut lesbar, auch durch den Einsatz der Inline-Variablen und deren strukturierenden Wirkung.

Bis bald...
Thomas

[himitsu]

Im C++, oder war's woanders, kannst'e auch Variablen mitten in der Bedingung von IF, WHILE usw. deklarieren.

Im Delphi sähe es dann so aus, falls wir irgendwann auch sowas können.

Delphi-Quellcode:

if restClient.BatchSend(var insRowIDs) = HTTP_SUCCESS then
  Result := Length(insRowIDs); 

//oder
if restClient.BatchSend(var insRowIDs: TIDDynArray) = HTTP_SUCCESS then
  Result := Length(insRowIDs); 


if GetValue(var Value) and (Value = 123) then

Gleich mal den Feature-Request erstellen. :duck:

[Uwe Raabe]

Da war wohl schon jemand schneller: https://quality.embarcadero.com/browse/RSP-36852

[Der schöne Günther]

Das ist wohl so geheim, da kann ich gar nicht draufklicken.

[Uwe Raabe]

Ich kann da jetzt nichts geheimes dran entdecken. Was passiert denn, wenn du auf den Link klickst?

[himitsu]

Vergessen einzuloggen? :stupid:

[Der schöne Günther]

Doch, war eingeloggt, bekam aber einen Fehler "Permission not granted" oder sowas. Jetzt geht es komischerweise.

[himitsu]

automatisch einloggen?

Niemals das anhaken.
Du verlierst nach Timeout dennoch deine Rechte, aber denkst du seist noch eingeloggt.