bCodeBlock := {|a,x|a += 10, x := a }
nNum := 10
xNeu := Eval( bCodeBlock, nNum )
x im Codeblock wird zwar als Parameter definiert, aber es wird beim Eval kein Wert an X übergeben.
Ich vermute, das ist eine Art der Variablendeklaration.
Der Codeblock funktioniert ohne den zweiten Parameter genau so.
Nun meine Frage: Ist diese Quasi-Deklaration für den Compiler besser zu handeln? Bringt das in irgendeiner Art einen Vorteil?
Exzessiver Codeblock Programmierer
--
Grüße
Sebastian
Allerdings ist es bei Xbase-Parts so, dass immer (na gut, es gibt Ausnahmen, aber wenige) die Parameter übergeben werden, die AppEvent() zurückliefert:
Damit werden auch Parameter übergeben, die eigentlich keinen Nutzen haben (in der Dokumentation meist mit uNIL1, uNIL2 bezeichnet). Durch diese Parameter, die immer übergeben werden, ist die Methode :handleEvent() für alle Xbase-Parts vom Aufruf her identisch. Das macht es für den Programmierer einfacher.
Falls Du eine ganz andere Frage hattest, bitte etwas deutlicher formulieren.
ich mache das auch öfters so, weil ich mir dadurch die Deklaration einer localen Variable in der entsprechenden Procedure spare, die nur in diesem einen Codeblock benötigt würde. So habe ich im Codeblock eine detached locale Variable, die nur im Codeblock sichtbar ist. Sauber gekapselt und legitim.
klammerauf hat geschrieben: ↑Sa, 02. Dez 2023 17:14
Dabei werden oft zusätzliche Parameter im Codeblock definiert, die aber gar nicht übergeben werden:
x im Codeblock wird zwar als Parameter definiert, aber es wird beim Eval kein Wert an X übergeben.
Ich vermute, das ist eine Art der Variablendeklaration.
Der Codeblock funktioniert ohne den zweiten Parameter genau so.
ich denke nicht dass es das Gleiche ist, ich kann mich zwar irren (ist lange her), aber ich denke der Unterschied liegt im Variablen Typ !
bCodeBlock := {|a,x|a += 10, x := a } => X ist hier local, könnte auch übergeben werden, hat aber nie Nebenwirkungen, da er nur im Codeblock als Variable existiert.
bCodeBlock := {|a|a += 10, x := a } => X ist hier private, das könnte Nebenwirkungen haben (je nach anderem Code).
Je nachdem, mit wie vielen Parametern ich "Meines" aufrufe, bekomme ich deren Inhalte oder NIL. Mit DEFAULT b TO <whatever> (oder hantieren mit pCount(), was auf dasselbe hinausläuft) kann ich das Verhalten ändern, aber "b" ist immer LOCAL.
genau, aber NUR weil es als Parameter zwischen den Klammern steht.
Wenn du es einfach im Quellcode darunter nutzen würdest,
wären es private, ab dieser Funktion - falls diese private nicht schon bekannt ist.
Ruft die Funktion weitere auf, würden diese die private sehen, falls im Hauptprogramm auch eine solche existieren würde, ist der Ärger vorprogrammiert.
Und beim linken werden die privates ja auch gemeldet (zumindest bei meiner Einstellung).
FUNCTION Meines(a,b,c)
xyz := "sowas geht ja auch"
? a // ist local
? b // ist local
? c // ist local
? xyz // ist private --- sichtbar je nach Vorkommen im Hauptprogramm ab hier oder überall
RETURN NIL
genau, aber NUR weil es als Parameter zwischen den Klammern steht.
Wenn du es einfach im Quellcode darunter nutzen würdest,
wären es private, ab dieser Funktion - falls diese private nicht schon bekannt ist.
Genau wie bei Funktionen, wie ich geschrieben habe.
Das ist überall im Code so. PRIVATEs entstehen durch Zuweisung an Symbolbezeichnungen, die nicht zuvor auf irgendeine Art (Parameter, LOCAL) als LOCALs deklariert wurden.
Jetzt fehlt mir nur noch ein Fazit. Ist es jetzt besser mit LOCAL statt mit PRIVAT Variablen zu arbeiten? Dient das der Geschwindigkeit oder dem Speicherverbrauch? Gerade im Hinblick auf Codeblocks, wo ich diese Variablen verwende.
Exzessiver Codeblock Programmierer
--
Grüße
Sebastian
LOCALs werden zur Compilezeit Symbolen zugeordnet und sind eindeutig, während für PRIVATEs und PUBLICs eine andere Art von Variablenverwaltung genutzt wird. Es gibt da eine Symboltabelle, die alle PRIVATEs und PUBLICs verwaltet, und dann vermutlich auch die Pointer zum Speicherplatz. Wenn man also solche Variablen anspricht, wird nach ihnen gesucht, und da sie auch noch gleichrangig mit Feldnamen in Tabellen eingesetzt werden können, wird vermutlich auch noch in der DBE rumgestochert. All das kostet im Vergleich zu LOCALs, die sozusagen auf dem lowest Level unterwegs sind, Performance, allerdings heutzutage nur noch in geringem Maße spürbar. PRIVATEs und PUBLICs haben aber den Vorteil, dass man sie z.B. in XPF-Dateien speichern kann (persistieren), dass man ihre Namen auch in zur Laufzeit erzeugten Codeblöcken, die aus Strings entstehen, verwenden kann, und richtig datengetriebene Anwendungen sind auch nur mit ihnen möglich. LOCALs sind Purismus und schneller und zudem sicherer (weil sie wirklich nur innerhalb einer Funktion gelten, und es nicht passieren kann, dass andere Funktionen, die versehentlich die gleichen Variablennamen verwenden, versehentlich Werte ändern), aber es hängt von der Situation und vom Bedarf ab.
Dazu gibt es viele, viele Threads hier im Forum. Viele, viele, viele.
