Lokale Variablen auf 1 Script beschränken

  • Hallo.

    Vor kurzem hatten wir die Rede von den lokalen Fake-Variablen in globalen Bereich. Allerdings wurde noch nicht geklärt, was das denn ist. Nun ist es wichtig geworden für Variablen, die nur in einem bestimmten Script verwendet werden sollen.

    Zum Beispiel habe ich ein Script_A das in andere eingebunden werden kann und dort Funktionen zur Verfügung stellt. In Script_A werden Daten in Variablen gespeichert, auf die die verschiedenen Funktionen zugreifen können. Wird Script_A eingebunden in Script_B, sollen dort die "lokalen" Variablen NICHT verfügbar sein. Wie kann man das erreichen?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    • Offizieller Beitrag

    Wir hatten vor viiiiielen Jahren mal eine Diskussion zur Vermeidung Globaler Variablen. Da hatte ich zwei Funktionen zum Variablenmanagement erstellt (tun beide dasselbe), um alle Variablen im Lokalen Namespace einer Funktion zu halten. Die Variablen werden intern im Skript als Strings verwendet.

  • Zum Beispiel habe ich ein Script_A das in andere eingebunden werden kann und dort Funktionen zur Verfügung stellt.

    Das ist ja die Beschreibung einer klassischen UDF Library. Wie die Benamsung von Variablen in UDFs vorgeschlagen wird, findest Du hier:
    http://https//www.autoitscript.com/wiki/UDF-spec#Variables

  • water - Leider funktioniert dein Link nicht. ;) Die Seite konnte ich dennoch finden. Danke für den Tipp!

    BugFix - Sieht aus als stecke da eine Menge arbeit drin. Vielen Dank!

    Nachträglich hat mir deine Arbeit eine Idee beschert, ob man es nicht einfacher lösen könnte, indem man eine "Aufbewahrungs"-Funktion mit Static-Varialben ersinnt. Dazu wäre es allerdings nötig, dass eine Static-Var nach dem Funktionsaufruf bestehen bleibt. Ist dem so?

    Zwar habe ich ein wenig recherchiert und auch die AutoIt-Hilfe zu Static durchgelesen, aber so ganz klar ist das nicht. Nur soviel glaube ich verstanden zu haben: Ob Global, Local, oder Static -> im Script-Root (globaler Bereich?) ist alles egal. Bringt alles nichts zum Einschränken des Scopes. Ich konnte noch nicht mal einen Unterschied finden. :/

    Die oben genannte "Aufbewahrungs"-Funktion stelle ich mir ungefähr so vor, dass sie einfach nur Static-Variablen enthält (z. B. Static $iCount, $sText, usw.) und als Aufrufparameter "Get", "Set", evtl. noch "Init" und natürlich den Var-Namen, den man abfragen will. Wenn es also stimmen würde, dass Static-Vars nach dem Funktionsaufruf erhalten bleiben, könnte man doch daraus was basteln. Zumindest wären die Variablen nicht mehr außerhalb der Funktion zu erreichen, und somit nicht mehr aus Versehen in einem anderen Script.

    Ein Haken wäre allerdings der Abruf einer Variablen. Dazu wäre es nötig, eine Variable mit Namen anzusprechen. Gibts so eine Funktion? Beispiel-Aufruf: _VarStorage("Get", "$iCount")

    Jetzt müsste man natürlich den Text "$iCount" der Variablen $iCount zuordnen. Geht sowas? (ohne Arrays? Mit Arrays wirds wahrscheinlich wieder zu viel Aufwand.)

    ...

    Ok, jetzt wo ichs geschrieben habe, kommt mir das doch sehr bekannt vor :Face: ... öhem, ... ist wohl so ziemlich das, was du in deinem Code schon umgesetzt hast.

    Über Tipps und Infos freue ich mich!

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    Einmal editiert, zuletzt von Professor Bernd (9. August 2019 um 17:06)

    • Offizieller Beitrag

    Na genau diese 'Aufbewahrungsfunktion' ist doch mein _Obj/_ArrVarsHandler.

    Static Variablen behalten ihren Wert auch nach dem Funktionsaufruf. Innerhalb der Funktion als Local Static sind es somit Lokale Variablen die man aus der Funktion abfragen und die man ändern kann. Genau was du willst.

  • Ja, manchal ist man wie vernagelt, oder anders ausgedrückt, man sieht den Wald vor lauter Bäumen nicht. :whistling: Danke dir!

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Noch zur Vollständigkeit:

    Dass es keine dateispezifischen Scopes geben kann, wird schnell klar, wenn man überlegt, was bspw. eine Anweisung wie "#include" ist.

    Man nennt diesen Typ von Anweisungen auch Präprozessoranweisungen. Was ist das? Ein Präprozessor ist ein Programm, was den Code durchgeht und genau diese Anweisungen ausführt/auswertet, BEVOR alles dann an den Interpreter/Compiler übergeben wird. Das heißt im Falle von Include also, dass der Präprozessor diese Anweisung erkennt, dann die dort angegebene Datei einliest und deren Inhalt anstelle der Include-Anweisung in das Skript einfügt. Diese Anweisung ist nebenbei an den C-Präprozessor angelehnt. Jedenfalls sieht der Interpreter/Compiler später gar nicht mehr, dass das eigentlich mal zwei (drei, vier, N) Dateien waren. Daher kann er auch nachher nicht mehr den Zugriff auf eine Variable verbieten, die nur in einer Datei vorkommt.

  • Da lob ich mir die Header-Dateien von CPP. Naja, eigentlich nicht, ich fand die immer ganz grausam. Aber immerhin konnte man mit deren Hilfe steuern, was in cpp-Dateien sichtbar sein sollte.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Was jetzt? Lob oder Nicht-Lob? Du musst Dich entscheiden ;)
    Die Tatsache, dass das bisher keiner/wenige gebraucht hat/haben, erklärt auch, warum das in AutoIt nicht implementiert ist. AutoIt sollte ja eine einfache, an VB angelehnte Sprache werden (was mMn auch gelungen ist).

    Unterschiedliche Bedürfnisse führen zu unterschiedlichen Implementierungen. Daher gibt es ja auch zig-hunderte Sprachen. Für jeden Zwecke eine :)

  • Lob oder nicht Lob, ... Kennt ihr das auch, wenn man jemanden eine Oder-Frage stellt und der antwortet mit "Ja"? Ich krieg dann immer die Kriese, wenn ich meine Frau frage "Holtst du die Kinder ab, oder soll ich das tun?" -> sagt sie: "Ja!" *Nackenhaare-aufstell*

    C bzw C++ war immer meine "Lieblings"-Programmiersprache. In meiner Ausbildung haben wir damit angefangen, so ungefähr vor 65 Mio. Jahren war das wohl!? :/ Damals habe ich Header-Dateien gehasst, vorallem weil dir niemand erklärt hat (oder konnte?), wie die genau funktionieren. Somit kann ich dir auf die Frage mit einem ganz klaren jein antworten. 8o


    Daher gibt es ja auch zig-hunderte Sprachen.

    Nun gut, Hausaufgaben: Bis Montag lernt ihr die ersten Hundert! :P

    Professor Bernd.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.