Hi, I was thinking for an implementation it would be good to have a core set of routines in one module and have event based scripts in their own modules ... but this requires the calling across modules functionality which I think is in development. Can you give me an idea of how that is progressing? Thanks, Tony

Unfortunately this is still quite far away.

I have yet to decide upon the exact method of linkage between modules. I want it to be possible to exchange a linked module without having to change the other, kind of how a dll is manually loaded and bound to an application. Of course, this wouldn't stop you from using static linking between modules. I don't want to use function pointers though. What I have in mind right now is something like this. The script writes the following lines to link to another module:



As the code suggests this is done through preprocessor directives and is not something the library does automatically. The application will be free to expose functionality that allow a script to exchange a module for another as long as it uses the same function names. If a module isn't loaded when the function is called a script exception is thrown.

I would of course show exactly how this preprocessor could be implemented.

This is of course not yet finalized so if you have any suggestions on this, now would be the time to tell me.

I don't know how you refer to functions, variables, etc so this may not be possible, but why not something derived from how namespaces work?

// sample
//
// declare using an external module
use module1;

// to simplify the script processing, instead of like in C,
// require the external module name for all usage
int t = module1::GetVariable();

Yes, I may use the module name as namespace for the imported functions. But the actual calling of the functions is a minor issue. I have plans to implement true namespaces in the future so the scripts could easily import functions into a namespace that itself chooses.

The major issue is how the functions are imported.

The function interface must somehow be declared in the script so that the compiler knows how the calls are made. This declaration must work independently if the other module actually exists or not, because otherwise the modules must be compiled in order. It wouldn't be possible to make circular linking either. The host application must also be aware of the functions imported and from where so that it can control what links that are made, otherwise the script writer could potentially access functions it shouldn't.

I will probably not use the example I showed yesterday, though it will be something similar. I'll try to avoid preprocessing if possible. After all, I want AngelScript to be easy to use.

Calling across modules is indeed pretty difficult. The main problem is that you don't know which functions are available in a module before you compile it.

The actuall calling is the easy part, you simply take what is before :: and use it as the module name.

You could have a sort of pre-processing stage that checks which functions are avaiable in a module. This stage would be called as soon as an other module requests a function from that module.

//module1.asvoid print() {	echo("Module1::print() called\n");}//module2.asvoid print() {	module1::print();	echo("Module2::print() called\n");}

When AS compiles module2. It encounters the module1::print() statement. It resolves the name of the module to an ID and does the pre-processing stage. This stage reveals that there is a print() function in that module and procudes the needed bytecode for module2.