Support for loading dynamic code

[Feather]

The current popular scripting languages seem to support loading dynamic code, such as JavaScript, python, lua.
Of course we also have AutoHotkey-H to support this feature, but it is not officially supported.
2.1 Should there be some attempts in this regard?

[lexikos]

See Potential priorities for v2.1.

Some other features might spring up during development of modules. ...
The current implementation has a single global C++ object g_script, which owns all lines of code and global variables/functions, and has many other responsibilities. Parsing script code at runtime is potentially unsafe because a syntax error could effectively leave g_script in an invalid state, and this is one barrier to implementing a function for loading additional scripts at runtime. (It appears that AutoHotkey_H's addFile handles it by backing up and restoring the properties of g_script, but it does not appear to account for the possibility that an incomplete function or class is added to the global namespace.) The code would need to be refactored to properly implement modules, and at the same time it would become closer to ideal for allowing scripts to be loaded dynamically. Of course, a dynamically loaded script could itself be a module.

The support for modules does not require being able to parse script code at runtime. I consider the former to be a high priority, while the latter is a long term goal. While I am working on the code, the way that I implement changes is guided by both short term requirements and long term goals. If I find that the cost of implementing a function to load a module at runtime is low enough, I may implement it in v2.1; otherwise it will come later.

Having module support first may allow for a cleaner implementation and interface for functionality to load scripts at runtime. For instance:

• Parsed "global" functions and classes would be contained within a new module and not the main script, so in the event of a syntax error, the new module can be discarded and the script is left in its original valid state.
• Currently creating new variables at runtime isn't permitted because it would create inconsistency, due to load time optimizations and how assignments affect scope. Merging the parsed code into the main script would require creating new variables, whereas creating a new self-contained module would be no issue.
• The module itself would provide an object-oriented interface for the parent script to access or enumerate its exports.

If anyone has related ideas that might inspire further development of this, feel free to post about them. I mean: how the functionality would look or work, ways of using it or script ideas that it would facilitate.

[V2User]

Maybe it's not safe to achieve this. Because local variables can be changed outside their func with this feature. For example:

Code: Select all

f(txt){
	a:=1
	eval(txt)
	MsgBox(a)
}
f('a+=2')

But at the moment, I came up with a good idea suddenly which looks perfect.
Maybe the limited dynamitc feature obj.%prt% at present is almost sufficient. But the below class Exec with only one parameter will be a perfect addition to it and keep safe at the same time:

Code: Select all

obj1:={prpt1:1}
Exec(obj1).eval('this.prpt1:=5')

Any variables must not be supported except this in the string form code, which is the only parameter of the eval method.