abrken:

I'll answer your last question first: This will change the library interface. Though the changes won't be that big that you can't start using WIP 3 already.

Currently the script syntax is:

import void Function(int param) from "module";import void AnotherFunc() from "module";import void OneMoreFunc() from "module";

I am playing with the thought of changing this to:

import from "module" {  void Function(int param);  void AnotherFunc();  void OneMoreFunc();}

But that's not really the important change. I might even use both ways.

What I noticed when doing the tests for importing functions is that there can be a slight confusion between imported function IDs and script function IDs. The current loop for binding functions will change a little, but not that much that you can't start using WIP 3 already.

The code will probably end up something like this:



Basically, most of the functions that require a module name or module index will be moved into the module interface. There will be one more interface to keep track of but I think the interfaces will be more easy to understand and use.

Gyrbo:

I've had the same thoughts, and I just might go ahead and do something like that.

If anyone has any suggestion for how to improve the dynamic binding of modules now is the time to tell me. Give WIP 3 a try and give me your feedback.

Thanks.

Yes, I decided to include acCString and acCArray as integrated parts of the library, which meant changing the name of them to follow the naming standard of the library.

Are you using acCString/acCArray outside the library?

abrken:

Ooops from me too [wink]. I haven't compiled with the AS_DEBUG flag in quite some time. I'll do that to check the code.

You are doing some heavy integration with the library. It's only expected that you are going to have more work to do with each version.

zola:

I chose not to require the modules to be compiled in a specific order because it makes it easier to use. With the import statement a module can be correctly compiled even if the other module doesn't exist yet. You can even execute the code, but if an imported function is called before being bound you'll get a script exception.

I also wanted to allow rebinding afterwards, so that the imported functions could be exchanged at runtime, possibly even by a function called from the script itself.

Another reason why I didn't want to make it automatic is that I want to allow an application to have control over which functions that are bound. It might be that an application don't want to allow binding of all script functions, in which case it must verify what functions the script is trying to bind.

If I didn't have the above requirements I could have used automatic binding. However, I will probably do what Gyrbo suggested and provide a method that automatically binds all imported functions after compilation, which is probably what most want to do anyway.

After giving it a try I've decided not to create the separate module interface.

It got more awkward to work with the engine when using a separate interface. It became necessary to explicitly create the modules, and then keep track of references, etc. It was good that there was less parameters to pass with each call, but the negative impact outweighed the good ones.

I will still do some changes to the interface, but they will be minor and mostly cosmetic, e.g. using a struct for function IDs instead of just an integer (for compile time verification).

Just thought I'd let you know...