Re: New scripting engine - testers wanted!
Posted: Thu Dec 28, 2017 11:53 pm
**This post is in reply to a question which now seems to have been removed. The question revolved around how we create reusable and independent code modules so I may as well keep the reply here for interested parties. **
===========================
Yes you can do that.
Modules can separate code and variables etc. When you use the \Execute() method you are executing 'stand alone' code running in it's own inaccessible module. You would normally use this to call some function or other - but you don't have to.
If you call a function by it's direct name then minScript will search for any function matching the given name, starting first in the 'current module' (assuming the calling code lies within a module) and, if unsuccessful, it will then search all remaining modules. You can specify a particular module when you invoke a function using the 'moduleName:functionName' notation as with :
etc. which will of course direct minScript to utilise the particular function implementation in the named module. In this way you can have loads of functions scattered about all sharing the same name and still be able to select the particular one of interest at any given time.
You can define module level global variables by placing the relevant DIM statements outside of a function block. These variables are then available to all functions and methods lying within that same module, but they will be inaccessible to code in a different module etc. Again this means you can reuse variable names and so on. (If you want global variables which are accessible to all modules then use 'script' variables... which I haven't documented yet! You can define these in script -e.g. DIM $x AS INTEGER, or through PB code. Details will be in the docs. Script variables always begin with a $ character.)
You cannot have classes in different modules sharing the same name, however. I did this for several reasons; not the least of which is the fact that I didn't want any confusion between modules when creating class objects. I want every module to be able to access the exact same classes etc.
Creating independent modules is thus quite straight forward. Consider using classes; one class per module etc.
There is also the global class library into which you can place classes (again, I would advise one class per module) and have them available not just to every other module in your code object, but to all independent code objects! This is the way to share code on an application level. Unfortunately, you will have to await the documentation to see how to make use of the global class library - though it is very straight forward. The qdMin test editor is not equipped to make use of it however.
I hope this helps.
===========================
Yes you can do that.
Modules can separate code and variables etc. When you use the \Execute() method you are executing 'stand alone' code running in it's own inaccessible module. You would normally use this to call some function or other - but you don't have to.
If you call a function by it's direct name then minScript will search for any function matching the given name, starting first in the 'current module' (assuming the calling code lies within a module) and, if unsuccessful, it will then search all remaining modules. You can specify a particular module when you invoke a function using the 'moduleName:functionName' notation as with :
Code: Select all
LET x = module1:foo(a, b, c)
You can define module level global variables by placing the relevant DIM statements outside of a function block. These variables are then available to all functions and methods lying within that same module, but they will be inaccessible to code in a different module etc. Again this means you can reuse variable names and so on. (If you want global variables which are accessible to all modules then use 'script' variables... which I haven't documented yet! You can define these in script -e.g. DIM $x AS INTEGER, or through PB code. Details will be in the docs. Script variables always begin with a $ character.)
You cannot have classes in different modules sharing the same name, however. I did this for several reasons; not the least of which is the fact that I didn't want any confusion between modules when creating class objects. I want every module to be able to access the exact same classes etc.
Creating independent modules is thus quite straight forward. Consider using classes; one class per module etc.
There is also the global class library into which you can place classes (again, I would advise one class per module) and have them available not just to every other module in your code object, but to all independent code objects! This is the way to share code on an application level. Unfortunately, you will have to await the documentation to see how to make use of the global class library - though it is very straight forward. The qdMin test editor is not equipped to make use of it however.
I hope this helps.