Macro Variable auch als String nutzbar?

[Nino]

Für mich ist es ebenfalls kein Bug.

Es ist wirklich kein Bug, und Du hast den Grund ganz richtig erklärt.

[Nino]

Es mag vielleicht kein Bug sein, aber es ist wieder komplett anders wie es jede mir bekannte andere Programmiersprache macht, in denen Scopes richtig funktionieren.

Das Verhalten von PB ist hier logisch und einfach zu verstehen. Ich sehe kein Problem.

[Mijikai]

Das Verhalten von PB ist hier logisch und einfach zu verstehen. Ich sehe kein Problem.

Logisch ist es nicht.
Wenn es so wäre und wie erwartet funktionieren würde gäbe es auch keine Diskussion.

[Nino]

Logisch ist es nicht.

Doch.

Wenn es so wäre und wie erwartet funktionieren würde gäbe es auch keine Diskussion.

Diese Schlussfolgerung ist nicht logisch.
"Wie erwartet funktionieren" ist etwas anderes als "logisch", und diese Diskussion hier gibt es unter anderem auch deshalb, weil einige anscheinend nicht verstanden haben wie unter PB Makros und/oder Module funktionieren.

[GPI]

Das verhalten ist absolut logisch, weil es sonst massive Probleme mit den Scope geben würde.

Code: Alles auswählen

DeclareModule test
  aloha=20
  Macro test2(_value_)
    aloha = _value_
  EndMacro
EndDeclareModule
module test
endmodule

value=10
aloha=30
test::test2(value) ;Macro - welches Aloha? Das in "root"-Scope oder das in Module test

ein Macro sind "Scope"-Los. Sie werden ausgeführt, bevor alles andere gemacht wird. Quasi ein Pre-Compiler wenn man so will.
Ansonsten hast du das Problem oben: Es gibt zwei Alohas - einmap in Module test und einmal außerhalb - welches ist gültig?
wenn das aus den Scope Test gültig ist, da gibt es kein Value (setzen wir ja ein).
Oder sollte vor den Macro quasi ein "UseModule Test" ausgeführt werden? Dann gibts eine Compilerfehlermeldung sobald das Macro benutzt wird, da es in Root und in Test ein Aloha gibt und das darf auch nicht sein.

Das Verhalten ist absolut logisch aufgebaut. Man mag es vielleicht nicht erwarten, aber es ist logisch und nachvollziehbar.