1. Yes, and no. I'm still working on the full implementation of casting in AS, but it is already working somewhat. You can cast to primitives, either through int(epxr) or cast<int>(expr). I think of the first as the construct cast, i.e. it creates an int 'object' from the expr, and the second as the cast operator. You can also register constructors for your types that can be used by the cast operator to allow casts between types. In a future version I'll also add the possibility of registering cast behaviours (instead of constructors), as well as easier casting between classes related to each other.

2. Just register the functions in math, as you would any other global function, e.g. RegisterGlobalFunction("float sin(float)", asFUNCTION(sinf), asCALL_CDECL); Of course, if your target system doesn't support native calling conventions yet, then you'll have to write the wrapper that uses the generic interface.

3. Handles are sort of like smart pointers in C++. In AngelScript they are stored as a pointer to the object, and AngelScript makes sure to increment and decrement the reference count of the object as necessary when manipulating the pointer. For an object to support handles, you need to register the ADDREF and RELEASE behaviours. Since with AngelScript I'm trying to provide a safe environment for development, i.e. without loose pointers or memory leaks, you'll find that by supporting handles in your objects you're getting a more flexible way of working with them, i.e. with handles AngelScript will let you pass the type by reference to a functions without any restrictions. Without handles AngelScript will only let you pass the type by reference in one direction, i.e. either 'in' or 'out'. Handles will also allow you to do polymorphing for script classes that implement interfaces, since AngelScript is able to determine the true class from the handle to an interface, and thus let you cast to the parent class, or any other interface it implements.

I hope that helped a little. :)

Regards,
Andreas

PS. I know, I really need to put these things in the documentation.

The constructor is only mandatory if the object stores information that must be initialized at allocation, e.g. virtual function table, reference counter, or pointers to other objects.

The destructor is only mandatory if your object needs to free resources upon destruction, and doesn't have the addref/release behaviours registered. If the addref/release behaviour is registered AngelScript will never call the destructor, since that is the responsibility of the release behaviour.

Regards,
Andreas

Actually, that behaviour is controlled by the parameter asOBJ_CLASS_CDA sent to RegisterObjectType. The acronym CDA means (C)ONSTRUCTOR, (D)ESTRUCTOR, (A)SSIGNMENT, i.e. this flag should be used for classes with all three of these. For classes that have only a contructor defined the parameter should be asOBJ_CLASS_C, and so on.

AngelScript doesn't use the registered constructor, or lack of registration, to determine how the class should be passed to the C++ application. It wouldn't work since the application is allowed to register constructors for C++ types that normally don't have constructors, and so on.

Indeed. That's why it is important to pay attention to the asOBJ_CLASS_??? parameter when registering types. I wish there was some way of determining this value automatically, but I've yet to discover how.