ideally, speaking of inheritance, 3 cases:

- C + + declares a class > C + + declare a subclass of that class
this is specially useful if you have some classes to publish to the script which are already inherited each other, but this will occur specially with virtuals.


class A {
public: void run () { cout << "A"; }
};

class B : public A {
public: void run () { cout << "B"; }
};

engine->registerObjectType ("A", sizeof(A), CLASS, NULL);
engine->registerObjectMethod ("A", "void run()", asMETHOD(A, run), asCALL_THISCALL);
engine->registerObjectType ("B", sizeof(B), CLASS, "A");
engine->registerObjectMethod ("B", "void run()", asMETHOD(B, run), asCALL_THISCALL); // this should just replace original method description for the B class, leaving the ability to call cast<A>(b).run()


so the script will be able to

A a, B b;
a.run (); // will output "A"
b.run (); // will output "B"


casting it should call the base function

B b;
A@ a = cast<A> (b);
a.run (); // will output "A"


- C + + declares a class > script declare a subclass of that class
this is the most common case, and will let the script environment to change
at runtime some parts of the classes it will work with. This could be seen as a special case of interfaces registered from applications side in which you aren't forced to implement all of its methods.


class A {
public: void run () { cout << "A"; }
};

engine->registerObjectType ("A", sizeof(A), CLASS, NULL);
engine->registerObjectMethod ("A", "void run()", asMETHOD(A, run), asCALL_THISCALL);


so the script will be able to

class B < A
{
void run () { script_cout << "B"; }
};

A a, B b;
a.run (); // will output "A"
b.run (); // will output "B"


or


class B < A
{
};

A a, B b;
a.run (); // will output "A"
b.run (); // will output "A"


imho this case could be the most difficult to implement since we have to mix c++ object representation with internal angelscript class representation.

- script declares a class > script declare a subclass of that class
this is obvious and a must have.

so the script will be able to

class A
{
void run () { script_cout << "A"; }
};

class B < A
{
void run () { script_cout << "B"; }
};

A a, B b;
a.run (); // will output "A"
b.run (); // will output "B"


or


class A
{
void run () { script_cout << "A"; }
};

class B < A
{
};

A a, B b;
a.run (); // will output "A"
b.run (); // will output "A"

Quote:
Implement try/catch statements in the scripts
The catch statement will allow the script to recover from an exception. The type of exception that was thrown can be accessed from the application, if it wishes to implement such a function.

This is cool :) Two questions:
1. Does this mean that I can use the C++ throw exception and the script side will beable to catch it?
2. Will this be top (or close to top) priority? :P I think this is really important as even &#106avascript has exception handling. I'm facing this exeption problem where I'm forced to use return value for all my script API. Not very intuitive when my C++ side already uses the C++ exception system.

Btw, cool script engine. I'll be sticking around this one for a long time. :D

AngelScript will be able to catch the C++ exception, but it will not be able to detect what type of exception it is. Another problem is if the exception has to be freed somehow, AngelScript wouldn't be able to know this and thus you would get a memory leak.

It will look something like this:

void scriptfunc(){  try  {     appFuncThatThrowsException();  }  catch  {     if( getException() == "application exception" )    {      print("An application function threw an exception");       }    else    {      print("Caught an unknown exception");    }  }}

The getException() function is a function registered by the application, and could for example call the asIScriptEngine::GetExceptionString().

The exception handling will thus not be as powerful as C++, but can be used to recover from errors where needed.

If you want to handle the C++ exceptions, then you must write a wrapper function that catches the C++ exception and then passes a script exception to AngelScript.

The priority of this feature is currently not at the top, but it is definitely not at the bottom either. I won't even try to give a due date.