DWScript has a “Globals” facility that allows storing and sharing data across scripts living in the same executable.
The first are Global Vars, and is a Key-Value storage, the second are Global Queues, which are LIFO/FIFO named queues. Both are thread-safe and high performance.
Enabling Support for Globals
To support them, just have dwsGlobalVarsFunctions in one of your project’s uses clause.
From that point on, all your scripts will have access to the Global Vars and Queues.
Delphi-side utilities are also exposed in that unit, and provide ability for the host application to debug, backup, etc.
Global Vars
Globals Vars storage is accessed through the ReadGlobalVar(name) and WriteGlobalVar(name, value) functions. They allow reading and writing a value by name, in an in-memory dictionary. Read & write operations are atomic.
While they’re quite self-sufficient on their own, you’ll usually want to access them through a minimal wrapper functions that’ll handle namespaces.
Here is the complete list of functions:
- ReadGlobalVar(name) : reads the variable of given name, returns Null if not defined
- ReadGlobalVarDef(name, default) : reads the variable of given name, returns default if not defined
- TryReadGlobalVar(name, var value) : attempts to read variable of given name, if defined places the value in value and returns True, otherwise returns False
- WriteGlobalVar(name, value, [expiration]) : writes value into the variable of given name, with an optional auto-expiration (in seconds)
- IncrementGlobalVar(name, delta = 1) : adds delta to the variable of given name and returns the resulting value
- DeleteGlobalVar(name) : deletes the variable of given name
- CleanupGlobalVars(filter = ‘*’) : delete variables matching the specified filter (wildcards ‘*’ and ‘?’ are supported). Memory is compacted if relevant. An empty string as filter will essentially just run a compaction operation.
- GlobalVarNames : returns an array of string that holds the names of all variables
- SaveGlobalVarsToString : returns a streamed persistence of all global vars
- LoadGlobalVarsFromString : loads a streamed persistence of all global vars
Global Queues
Global Queues are named chains of values which can be used both as a LIFO and FIFO queues. Writing or reading from a queue is thread-safe and atomic.
While they’re quite self-sufficient on their own, you’ll usually want to access them through a minimal wrapper functions that’ll handle namespaces.
Here is the complete list of functions:
- GlobalQueuePush(name, value) : adds value at the tail of the queue of given name
- GlobalQueueInsert(name, value) : adds value at the head of the queue of given name
- GlobalQueuePull(name, var value) : removes a value from the head of the queue of given name, places it in value and returns True. If the queue is empty, returns False
- GlobalQueuePop(name, var value) : removes a value from the tail of the queue of given name, places it in value and returns True. If the queue is empty, returns False
- GlobalQueueLength(name) : returns the length of the queue of given name
- CleanupGlobalQueues : delete queues matching the specified filter (wildcards ‘*’ and ‘?’ are supported)
Nice.
But why use sets of functions instead of two (pseudo-)classes, which may help code completion in the IDE?
Is is available in SMS also? I know we do not need such globals in SMS, but sounds to me like HTML5 local storage, which can be shared inside the same domain AFAIK.
Two reasons mostly: the first is historical, while the GlobalQueues are recent, the GlobalVars functions are more than ten years old (they have been improved over the years of course). The second is that they’re quite low-level, and you’ll generally have some minimal class to handle the namespacing (ie. typically just prefix the name with a constant string), and those classes are the ones you’ll be using in completion.
The functions are really meant for use in DWScript. In SMS there are local & cookie storage objects which expose similar functionality to global vars (on a given domain). You can however use those function to easily build a memcached-like architecture on the server-side.