I was experimenting with the import functionality today, trying to implement some basic support for bound functions in our application. Our script modules, whenever they coexist, always share lifetimes, so I thought the simplest thing to do would be to automatically bind all functions once all scripts are loaded. I found the method asIScriptModule::BindAllImportedFunctions, which seemed like a useful shortcut, until I found out I can't see any way to test which imports succeeded. In particular, I hoped to create a simple bool isBound(const ? &in) function available to scripts, that would test whether an imported function is safe to use. I looked into implementation details, and it seems that an asCModule method which accomplishes it would be trivial to implement, as all it would have to do is test bindInformations[index]->boundFunctionId != -1. However, as I said, I was unable to find any such method. Does there exist one? If not, could it be added?

It's true. There is currently no interface for checking if an imported function has been successfully bound or not. If you need that information, it is easiest if you do the binding yourself, i.e. manually implement a routine that does the same thing as BindAllImportedFunctions, but keep track of the functions that couldn't be bound.

If you take a look at the implementation of the method BindAllImportedFunctions you'll see that it is quite simple. In fact, I have long thought about retiring it completely from the core engine, and instead put it in the helper add-ons.

Actually, I'm planning on redesigning the import feature completely at some time in the future. That's why I haven't put much energy into making it easy to use, not even documented it.

I see. Our application aims for high forward compatibility of scripts, so if it's awaiting a redesign, perhaps it's better if we currently resign of import altogether and try to use a more future-proof approach.

You can use an approach similar to C/C++ where you manually assign function pointers. This could be made simpler for the script writer through the use of pre-processor macro. This is in fact what I had planned to do in order to keep something similar to the current import feature once I go ahead and retire it so that those who use it don't get totally left out.

Thanks. After your previous response, I actually visited the AngelScript to-do page and noticed what improvements you had in mind. Our team was discussing whether to adapt a similar approach, but for now I'll be trying something different. It's a similar concept, but rather than import functions, I'm importing interfaces. The exporting module registers a class C that implements a shared interface B, which in turn inherits from an application-registered empty interface A. It also registers a hook that returns an instance of class C. The importing module calls an application-registered function that calls the hook in another module and returns its result as a handle to A. This result is then cast to a handle of B, which is possible because it is shared. This way the importing module can call methods of an instance in another module.

This approach is not as straightforward as imports, but it has its advantages. It's safer, because a module may only import a selection of functions that are meant to be imported, rather than just any function it desires. On the importing side of the code, it often ends up shorter, because a single import gives the script access to all functions of another module (the shared interface B can be placed in a separate header file that just has to be #included). The most complicated part of code ends up on the exporting side, which I think is a fair price, because I expect modules that expose a functionality, akin to libraries, to be only written by the more experienced users.