I thought I would let you guys know how progress is going on AS 2.0, as it's been quite a while since I released a WIP version. Well, AS 2.0 WIP 1 is very close to being released. I'm just doing some final touches to get the library working enough for you all to take a look at it. The major changes are as follows: The interface for setting script function arguments and getting the return value has been changed to be much more intuitive. You will for example call SetArgObject(int argnum, void *object) to pass an object to a script function. The library will then automatically make a copy of the object if the it is meant to be passed by value. To get a returned object you will call GetReturnObject() which returns a pointer to the object. The application should then make a copy of the object (simply assign it to another object) as the library will release it when the context is released (or reused).

CObject obj();
ctx->Prepare(func);
ctx->SetArgObject(0, &obj);
ctx->Execute();
obj = *(CObject*)ctx->GetReturnObject();

The script language no longer have pointers. The functionality of pointers will be replaced with something else (I'll describe it later). That the script language doesn't have pointers doesn't mean that you can't pass pointers to the scripts. The script language supports passing parameters by reference, and if that is not enough it is possible to register a special data type for holding the pointer. Internally, the library stores all objects in dynamic memory. This allows for customized memory management per object. It's quite common to use memory pools to store game entities, for example. The script library will be able to support this. The application will just have to register the memory allocation and deallocation functions for that object type. Externally this doesn't change much, except maybe for a slight performance hit due to the dynamic memory allocations. Exactly how large this performance hit will be remains to be seen. If it is too large I will do what is possible to minimize it by using static memory allocations where possible. I mentioned that pointers will be replaced with something else. This is because all objects are treated by value, so without something similar to pointers it is not possible to do something as simple as a linked list. What AS will do is support object handles. An object handle is a pointer to an object, but it automatically handles reference counts. This implies that the object must allow reference counting for object handles to be allowed. I won't force the application to register functions for reference counting on every object type, but if it doesn't then it will not be possible to use object handles on those types. This also implies that object handles cannot be declared for primitives. The syntax for these object handles could be the same as for C++ pointers. But I'm not sure I will go that way yet. I would like to make the language the least confusing as possible (to newcomers) in regards to object handles. I think that by default an object handle would work just as if it was the actual object (like object references). I think that is all for now. Hopefully I'll be able to release the first WIP in a couple of days. Regards, Andreas

Sounds nice, but I have some questions in regards to the pointer replacement. If I understand correctly, the application is responsible for maintaining the reference count, returning a reference, etc.? Could you provide some sample code as to how this would be handled, because it's not clear at all to me how this would work.

Well, it's not 100% defined yet. But I do know that in order for object handles to work AngelScript needs to have some way of controlling when an object is to be deallocated or not. Since AngelScript can work directly with objects allocated by the application this has to be done through an interface defined by the application. What I figure is that the application registers a couple of functions (for each object type): AddRef() and Release(). AngelScript will then use these to notify the application that it is holding extra references to the object. If the application don't register these functions, then AngelScript will not allow handles to be declared for that object type.

For example: a Vector3 class which is quite common usually don't have any way to count references, thus won't be able to use object handles. But a game entity could easily have a reference count, which would allow the use of object handles.

I figured this is the only way AngelScript will be able to synchronize memory management (or garbage collection) with the application.

An object handle like this is passed to the application as a simple pointer to the object. The application will then be responsible for releasing the object as necessary.

Soon AngelScript will allow declaration of classes inside the scripts as well. These classes will automatically allow object handles to be used.