just me, ich hab das ein klein wenig anders verstanden.
Ich glaube nicht, dass das
implizite Return tatsächlich eines ist, das auf der
gleichen Zeile (wie das
If bzw. der Zeile des Einzeilers) vom Interpreter eingefügt wird, sondern
de facto immer als zusätzliche, eigenständige Zeile behandelt wird (natürlich könnte man das im Quellcode des Interpreters nachgucken
) .
Ja, eine Fehlermeldung bzw.
ListLines zeigt für das implizite Return zwar die gleiche Zeilennummer an wie die Zeile des Einzeiler-Hotkeys, aber wenn dem impliziten Return stattdessen eine eigene, zusätzliche, neue, Zeilennummer gegeben würde, würden alle anderen Zeilennummern sich als Folge verschieben und nicht mehr mit den Zeilennummern im Editor übereinstimmen und für den Benutzer ganz bestimmt zusätzliche Probleme verursachen.
Wo sollte der Endnutzer diese neue,
implizite Zeilennummer in seinem Quellcode finden? Zur Zeit hat er dagegen einen Hinweis, welche Zeile das implizite Return
ausgelöst hat.
Wenn man bei diesem Code erst
1 und dann
2 drückt
Code: Select all
x := "" ; 001
1::MsgBox ; 003
2::Listlines ; 004
erhält man dies als
ListLines-Ergebnis:
Code: Select all
001: x := ""
003: Return (1.47)
003: MsgBox (0.91)
003: Return (0.38)
004: ListLines
Das zeigt, bei diesem Einzeiler-Hotkey sind sogar zwei implizite Returns auf der gleichen Zeilennummer wie der erste Hotkey angegeben (Zeile 003).
Das erste (
003: Return (1.47) ) ist das implizite Return vom Ende der
auto-execute section, das ja auch irgendwo auftauchen muss und beim ersten Start des Skripts gebraucht wurde (bei weiteren Aufrufen des gleichen
1-Hotkeys erscheint dies dann nicht mehr unter ListLines, weil dann im Vorfeld keine auto-execute section mehr durchlaufen wird).
Das zweite (
003: Return (0.38) ) ist das implizite Return, das formal den Einzeiler abschließt. Und das steht hier formal sogar für die selbe Zeile wie das msgbox-Kommando verzeichnet, nicht auf der Zeile eines (traditionellen oder irgendeines) If - macht rein syntaxmäßig eigentlich auch keinen Sinn. Zum debuggen schon eher.
Wäre das erste Implizite Return tatsächlich vom Interpreter physikalisch auf der gleichen Zeile (003) wie der Einzeiler-Hotkey eingefügt worden - und noch vor dem Hotkey selbst - dann dürfte der Hotkey selbst ja unerreichbar sein bzw. ungültige Syntax und eine Fehlermeldung erzeugen.
Das zweite hätte auf einer Zeile mit
msgbox normalerweise auch keine returnierende Wirkung.
Folgerung:
Implizite Returns werden vom Interpreter bei Ausführung immer als zusätzliche, eigenständige Zeilen eingefügt - erhalten jedoch keine eigene Zeilennummer.
ListLInes und Fehlermeldungen geben stattdessen die Zeilennummer des
verursachenden Hotkey-Einzeilers für dieses implizite Return an - vermutlich, damit es bei Analyse besser der auslösenden Zeile zugeordnet werden kann und damit die Zeilennummmern für folgende Zeilen (tatsächlich vorhandene im Quelltext) noch immer aussagekräftig beim debuggen bleiben.
Wie gesagt, eine zweizeilige Konstruktion wie if in einem Einzeiler, wo die nächste Zeile schon feststeht (Return), zu verwenden, hat wenig Nutzwert - aber formal ist es derzeit möglich (bzw. erlaubt), da implizite Returns als eigenständige Zeilen zur Laufzeit eingefügt werden. Es wäre wohl nicht viel verloren, wenn der Interpreter If in Einzeilern grundsätzlich unterbinden würde.
just me, ich hab das ein klein wenig anders verstanden.
Ich glaube nicht, dass das [i]implizite Return[/i] tatsächlich eines ist, das auf der [i]gleichen[/i] Zeile (wie das [docs]If[/docs] bzw. der Zeile des Einzeilers) vom Interpreter eingefügt wird, sondern [i]de facto[/i] immer als zusätzliche, eigenständige Zeile behandelt wird (natürlich könnte man das im Quellcode des Interpreters nachgucken ;) ) .
Ja, eine Fehlermeldung bzw. [docs]ListLines[/docs] zeigt für das implizite Return zwar die gleiche Zeilennummer an wie die Zeile des Einzeiler-Hotkeys, aber wenn dem impliziten Return stattdessen eine eigene, zusätzliche, neue, Zeilennummer gegeben würde, würden alle anderen Zeilennummern sich als Folge verschieben und nicht mehr mit den Zeilennummern im Editor übereinstimmen und für den Benutzer ganz bestimmt zusätzliche Probleme verursachen.
Wo sollte der Endnutzer diese neue, [i]implizite[/i] Zeilennummer in seinem Quellcode finden? Zur Zeit hat er dagegen einen Hinweis, welche Zeile das implizite Return [i]ausgelöst[/i] hat.
Wenn man bei diesem Code erst [kbd]1[/kbd] und dann [kbd]2[/kbd] drückt
[code]x := "" ; 001
1::MsgBox ; 003
2::Listlines ; 004[/code]
erhält man dies als [docs]ListLines[/docs]-Ergebnis:
[code]001: x := ""
003: Return (1.47)
003: MsgBox (0.91)
003: Return (0.38)
004: ListLines[/code]Das zeigt, bei diesem Einzeiler-Hotkey sind sogar zwei implizite Returns auf der gleichen Zeilennummer wie der erste Hotkey angegeben (Zeile 003).
Das erste ( [c]003: Return (1.47)[/c] ) ist das implizite Return vom Ende der [i]auto-execute section[/i], das ja auch irgendwo auftauchen muss und beim ersten Start des Skripts gebraucht wurde (bei weiteren Aufrufen des gleichen [kbd]1[/kbd]-Hotkeys erscheint dies dann nicht mehr unter ListLines, weil dann im Vorfeld keine auto-execute section mehr durchlaufen wird).
Das zweite ( [c]003: Return (0.38)[/c] ) ist das implizite Return, das formal den Einzeiler abschließt. Und das steht hier formal sogar für die selbe Zeile wie das msgbox-Kommando verzeichnet, nicht auf der Zeile eines (traditionellen oder irgendeines) If - macht rein syntaxmäßig eigentlich auch keinen Sinn. Zum debuggen schon eher.
Wäre das erste Implizite Return tatsächlich vom Interpreter physikalisch auf der gleichen Zeile (003) wie der Einzeiler-Hotkey eingefügt worden - und noch vor dem Hotkey selbst - dann dürfte der Hotkey selbst ja unerreichbar sein bzw. ungültige Syntax und eine Fehlermeldung erzeugen.
Das zweite hätte auf einer Zeile mit [docs]msgbox[/docs] normalerweise auch keine returnierende Wirkung.
Folgerung:
[color=#008000]Implizite Returns werden vom Interpreter bei Ausführung immer als zusätzliche, eigenständige Zeilen eingefügt - erhalten jedoch keine eigene Zeilen[i]nummer[/i].[/color]
ListLInes und Fehlermeldungen geben stattdessen die Zeilennummer des [u]verursachenden[/u] Hotkey-Einzeilers für dieses implizite Return an - vermutlich, damit es bei Analyse besser der auslösenden Zeile zugeordnet werden kann und damit die Zeilennummmern für folgende Zeilen (tatsächlich vorhandene im Quelltext) noch immer aussagekräftig beim debuggen bleiben.
Wie gesagt, eine zweizeilige Konstruktion wie if in einem Einzeiler, wo die nächste Zeile schon feststeht (Return), zu verwenden, hat wenig Nutzwert - aber formal ist es derzeit möglich (bzw. erlaubt), da implizite Returns als eigenständige Zeilen zur Laufzeit eingefügt werden. Es wäre wohl nicht viel verloren, wenn der Interpreter If in Einzeilern grundsätzlich unterbinden würde.