Sign in to follow this  
WitchLord

The future of AngelScript

Recommended Posts

No, no, I'm not announcing that I'll stop working on AngelScript. Don't worry. This is my favourite project, and I'll probably never stop working on it. Unless perhaps I start over from scratch with another script engine. ;) No, what I want is to show a bit of the future for AngelScript, i.e. the features that I have planned for it. Some of these may never be implemented, others may still change, but all of them are things that I'm thinking about. Let me know what you think about these. Feel free to suggest improvements, or even tell me about potential problems that make a certain feature invalid.
  • The list at the AngelScript site. List updated Nov 21st, at 17:45 GMT -3. [Edited by - WitchLord on November 21, 2006 1:45:19 PM]

    Share this post


    Link to post
    Share on other sites
    that may be completely offtopic, but however:

    what about BMFont? are you going to continue to work on it too?

    not that there is something wrong, besides a small bug:
    when i choose a font that has no characters on another page and then reselect a font that has characters on other pages, the list on the right does not reappear ;-)

    also it would be nice if zero-amount kernings would not be exported and if the header included the number of exported characters. :-)

    thanks a lot!

    Share this post


    Link to post
    Share on other sites
    My 2 pennies... RE-EDITED

    Quote:

    - Context redesign -
    The context as it is now will be removed, and replaced by a new context
    interface and a thread interface.
    The context holds the environment in which threads are executed. Thus it will
    keep track of global variables and memory allocations, shared between threads.
    A thread will only control the execution of a script, i.e. hold the call stack
    while it is running. Thus it will not be necessary to keep the call stack in
    memory when it is not used.
    Unless, non-shared global variables are implemented, this redesign is pretty
    useless as the contexts will not hold anything.

    perfect, i was just trying to hack the engine to hold scripts in multiple threads,
    but with shared memory and locking mechanizms... i think a script could be
    spanned over a new thread when executed, while the main program is receiveing callbacks
    of the execution status. obviously the engine could allow to execute co-scripts instead
    of threads, depending on the needs. the context will manage locking and memory
    accesses of shared/non-shared globals.


    Quote:

    - Namespaces -
    With the addition of namespaces the scripts that previously had to be compiled
    in separate modules, can now be compiled in one module and still use the same
    names. The benefit for this is the better reutilization of common functions.
    Modules will still exist, of course.

    the namespace addition is something very useful for not dirtying the global
    namespace with lots of similar names, especially when dealing with global objects and configuration variables.


    Quote:

    - Shared/non-shared global variables -
    A global variable can be marked as shared between contexts, i.e. all contexts
    referencing the same module will access the same memory for that variable.
    A non-shared global variable is local to the context, i.e. each context has
    it's own instance of the variable.
    By default the global variables are shared.

    this is good, even if i don't use it too much, but some other people could...


    Quote:

    - Registerable context properties -
    A context property is a non-shared global variable registered from the
    application. After creating the context, the context property must also be
    set, otherwise a null pointer exception will occur.

    this is a bit obscure, could you explain it a bit more ?


    Quote:

    - Remove the bits types -
    I'll remove the bits type. The bitwise operators will instead work on the
    integer types.
    The advantage is the better compatibility with C++'s types. Easier automatic
    mapping of integer types to angelscript types and vice versa.
    The drawback is the lack of direct manipulation of bits in double or float
    types. But if this is wanted the application can easily write functions to
    allow the bitwise conversion for these types.

    ok 100% with you ! i've never used the bits type since i've registered a BitArray class that manages and check individual bits internally.

    Quote:

    - Add the int64 and uint64 types -
    Although not used a lot I want to add these types as built-in types, also
    for better compatibility with C++'s types.

    perfect! i was lacking these types when i've encountered some functions to publish in scripts that was playing with overall frames of a a played video streams...

    Quote:

    - Improved any type -
    I'll possibly rename the any type to 'var', which I feel is a better name.
    I want this type work more like the variants of javascript or VBScript, i.e.
    you should be able to assign any type to it, and then perform operations on it.
    All the operators should work, and the meaning will depend on the contents of
    the any type.
    It may not work for method calls, as that requires compile time knowledge of
    the type. So for objects, the type will only work as a container, but for
    primitives the type should work just fine. It will also work for string
    concatenations etc.

    yes, even this could throw in a lot of strange behaviours when dealing with multiple operations based on the "internal type" of the any: i think a massive use of the "var" will lead to a general confusion. one of the things that impressed my attention in AS is the strong typing: when u write script you are sure that what u write is what u intend to do. if i want to use dynamic objects that will hold everything i'll choose something like javascript, with function objects and all threated in the same way: but this can make you loose the control over the script and make you write something that can compile but produces incorrect unpredictable results (i've experienced this in a lot of web applications over there)...

    Quote:

    - Unified way to access script arguments -
    The SetArgDWord, SetArgObject, etc, functions will be replaced with
    GetArgPointer and GetArgTypeId(), likewise for return value. This will
    simplify the library implementation, and also make it easier to implement
    automatic argument assignments from outside the library, e.g. through
    templates.

    you mean SetArgPointer and SetVarTypeId or i'm wrong here ?

    Quote:

    - Static arrays -
    Allow use of static arrays in the scripts, e.g. int ar[3]. These will be
    directly compatible with C++ arrays. They will not be objects, so it will
    not be possible to store a handle for a static array, but they can be passed
    by reference to functions.

    whau this is weird ! it opens up a lot of interesting use cases
    and saves a lot of typing too !

    Quote:

    - Variable argument type -
    I'm thinking about allowing the application to register functions that take
    variable types as argument. It would look something like this: void func(?&).
    The function would then receive a reference to the value, as well as the type
    id.
    This can be useful for implementing generic container classes.
    When overloading a function with this type, the variable type has the least
    priority.

    - Variable argument count -
    I want to be able to support the ... parameter declaration. I will not
    implement it as loosely as C does it. Instead the function will receive the
    argument count, and be able to access both the value and the type of the
    value. This will make the use of the ... in scripts just as safe as any other
    function.
    The script will have to add an extra keyword for parameters if the argument
    is support to be a return value, something like: func( (out)arg );

    splendid! one of the thing i lack a lot is the default argument value
    for the functions. if i have something like this in c++:
    void x (int a = 0, int b = 1, int c = 2, int d = 3);
    i have to register 5 different functions all with
    "void x ();"
    "void x (int a);"
    "void x (int a, int b);"
    "void x (int a, int b, int c);"
    "void x (int a, int b, int c, int d);"
    could be avoided with only one call:
    register ("void x (int a = 0, int b = 1, int c = 2, int d = 3)",...)
    isn't it ?

    Quote:

    - Data structures -
    The struct will come back to AngelScript. Now it will be used to allow the
    scripts to declare the exact memory layout of a structure. There will be no
    hidden members of a struct, and the packing can be controlled exactly. This
    will make the struct compatible with C++ structs, and allow for easier data
    manipulation in complex memory layouts, such as data files, etc.
    It will not be possible to store a handle to a struct, nor will the struct be
    able to inherit from another class or struct.

    nice one. i was asking myself why the script structure desappeared
    from time to time !

    Quote:

    - AngelScript Manager -
    This is an addon for the script engine. Kind of a layer above the library.
    * It will make the engine easier to use.
    * It should implement the script loading with include management.
    * It should implement script execution with timeout and garbage collection.
    * It should implement concurrent script execution, and also co-routines.
    * It should also implement debugging features, such as variable enumeration,
    setting breakpoints, stepping through the code, etc.

    i agree with you, even if this could be difficult to delineate in a good
    interface. if you look into the angeljuice trunk, under
    AngelJuice_ScriptablEngine i've bundled all that features already. give it an
    eye, but forget to find a clean / polished interface (not yet!)

    Quote:

    - Engine properties -
    It should be possible to dynamically set some engine properties, such as
    ALLOW_UNSAFE_REFERENCES, ALLOW_POINTERS, etc. This will make the library
    equal for all, and make it easier to test these features as I can test all
    features without having to recompile the library.

    why not ? i think of a general engine modularity in which you can deliberately
    make use or completely remove support for unsafe references, pointers, structs and classes, interfaces, try catch blocks, and even let the programmer change slightly the "core" syntax, letting him choose if he wants "begin" over "{", or taking case into account when dealing with the syntax (use "InT x" instead of "int x" for example), even change the name of the registered base types (i know something of this can already be done, but i'm thinking more wisely) or suppress some of them (blocking the use of the floats/double type for examples).

    Quote:

    - Return of pointers -
    Implement pointer support again. Now with full support for access, type casts,
    etc.

    THIS IS THE MOST IMPORTANT THING I'LL LIKE TO SEE IMPLEMENETED SOON !
    (POINTERS ARE THE ONLY THING THAT MAKES ME STILL STICK TOGHETER WITH C++)

    Quote:

    - A super class for all script classes -
    Maybe a super class for all script classes can be implemented.

    interesting, but not so important. what kind of functions/properties it will hold ?

    Quote:

    - Automatic translation of the string type to other C++ built-in types -
    In C++ it is very common to use at least two different representations of
    character strings, e.g. std::string and char*. I want to allow AngelScript
    to automatically translate the registered string type to either of them so
    that the application doesn't have to use wrapper functions.
    It will probably need a new behaviour on the string type, as well as a new
    indicator when registering the function that needs the translation.

    yeah this is a must have... but i have a really kicking ass registered String class...

    Quote:

    Suggestion by Manu Evans.
    - Getters and Setters for properties -
    This will allow the application to register a couple of functions to
    manipulate properties.
    I need to investigate the complications of this. What happens for example
    if a property is passed by reference to a function?

    i don't see the point of being too similar with VB side of the moon...
    i better manipulate directly the properties, and if i need to do more things
    when getting/setting, i'll register the getters and setters manually from C++, and only if i need to !

    Quote:

    - Function pointers -
    Allow use of function pointers. I think I'll require a typedef to define the
    signature of the function, which will simplify the code.

    YEEEEEES ! this is even better than pointers to classes or variables... i think about having the possibility of passing a "void*" in the script and then explicit cast the function ...

    Quote:

    - Registerable cast behaviours -
    It should be possible to register cast behaviours for types, so that both
    implicit and explicit casts between registered types can be performed.

    another important strike ! i've already talk about this on the casting thread...

    Quote:

    - Registration of true constants and enums -
    It should be possible to register literal constants, and also enums.

    good one, but i also see a lot of use with the "static" word... static
    globals, static Class members, static Class functions: it will mimics much better when mapping a C++ object to its AS couterpart (i have a lot of static Class members registered as global function... and is a dirty situtation, especially when i look at the global namespace...)

    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.

    nice one, i lack this a lot !

    Quote:

    - Persistent script states -
    It would be great if it was possible to save/load the script state, including
    the context stack.

    interesting

    Quote:

    - Compile to native code JIT -
    This would definitely speed up the execution speed. I do not want to loose
    functionality though, such as the ability to set breakpoints, co-routines,
    etc.

    i agree, even this could slow down implementation of new features. i think
    this should be planned before starting to grow much implementing new features...
    i think this should be and addon, not a complete replacement...


    i will add:

    - Give a common definition to the bytecode, that should look the same on all
    architectures (big-little endian, mac, ppc, intel, mips) so a bytecode i have
    here, i can run it on any other implementation without worrying about its endianness -
    - Pragmas to configure the engine (stack sizes for example) when script will be executed -
    - Objects class inheritance as well as interface inheritance -
    - Possibility to decouple method declaration from implementation (ala C++) -
    - Possibility to not use this keyword inside the methods of an object -
    - Some sort of introspection tools to be used directly from the script side to know the type of the objects at runtime -
    - Bytecode optimizer: while browsing some time ago i've found another scripting engine out there that have an interesting feature, a bytecode optimizer... give it an eye, overall optimization could be even ~40% gain in execution speed ! (http://www.jewe.org/jewelscript/) anyway i don't mean to copy another project... -

    i think i'll sleep this night and post some more nightmares tomorrow ;)
    i'll keep this updated...

    [Edited by - kunitoki on November 6, 2006 4:16:20 PM]

    Share this post


    Link to post
    Share on other sites
    ehmdjii: Yes, I'll continue to work on BMFont as well. In fact, I have a new version of it already. I'll release it in a couple of days after just a little more adjustments.

    kunitoki: Excellent. This is the kind of feedback I wanted. I'll go through your comments and update my list at a later time, and also answer your comments individually.

    Share this post


    Link to post
    Share on other sites
    This is slightly off topic (as per feedback), but you have done an amazing job so far and I wanted to congratulate you on that. We have used AngelScript in the past for a school project and it turned out to be quite an adventure. Although today I tend to stick with a CLR profile (as a scripting language), AngelScript will always be one of the things I keep close at hand :-).

    NOTE: for function pointers in general, my advise would be to check out the latest C++ standard draft. They have a recently adopted a proposal for a neat fresh syntax for both static and member function pointers.

    Share this post


    Link to post
    Share on other sites
    Thanks for the compliments. Is there a link to your project anywhere, that we can check out, and I can link to?

    I'll check out the new standard draft. Thanks for the tip.

    Regards,
    Andreas

    Share this post


    Link to post
    Share on other sites
    Quote:
    Original post by kunitoki
    perfect, i was just trying to hack the engine to hold scripts in multiple threads,
    but with shared memory and locking mechanizms... i think a script could be
    spanned over a new thread when executed, while the main program is receiveing callbacks
    of the execution status. obviously the engine could allow to execute co-scripts instead
    of threads, depending on the needs. the context will manage locking and memory
    accesses of shared/non-shared globals.


    I do not intend to implement a multithreaded solution. At least not at this time. You can easily put the script engine and all script execution in a separate thread, but having one OS thread for each script thread is just asking for trouble.


    Quote:

    yes, even this could throw in a lot of strange behaviours when dealing with multiple operations based on the "internal type" of the any: i think a massive use of the "var" will lead to a general confusion. one of the things that impressed my attention in AS is the strong typing: when u write script you are sure that what u write is what u intend to do. if i want to use dynamic objects that will hold everything i'll choose something like javascript, with function objects and all threated in the same way: but this can make you loose the control over the script and make you write something that can compile but produces incorrect unpredictable results (i've experienced this in a lot of web applications over there)...


    Agreed. But it's up to the script writer to use whatever he wants. The main advantage of the any type is that you can write generic containers for them, for example hash tables to store any value you want by name.

    Quote:

    you mean SetArgPointer and SetVarTypeId or i'm wrong here ?


    No, I mean GetArgPointer and GetVarTypeId. See my update.


    Quote:

    nice one. i was asking myself why the script structure desappeared
    from time to time !


    The structure that I had was identical to the current script class. I want to keep the language as clean as possible, so I removed the struct, but now I'll add it again with a new flavour.

    Quote:

    - AngelScript Manager -
    i agree with you, even if this could be difficult to delineate in a good
    interface. if you look into the angeljuice trunk, under
    AngelJuice_ScriptablEngine i've bundled all that features already. give it an
    eye, but forget to find a clean / polished interface (not yet!)


    Agreed, the manager will not fit everyone, that's why I'll make it an add-on instead of part of the core library. It will also serve as a good example for others wanting to implement their own managers.

    I'll take a look at the solution you implemented for AngelJuice.




    Quote:

    why not ? i think of a general engine modularity in which you can deliberately
    make use or completely remove support for unsafe references, pointers, structs and classes, interfaces, try catch blocks, and even let the programmer change slightly the "core" syntax, letting him choose if he wants "begin" over "{", or taking case into account when dealing with the syntax (use "InT x" instead of "int x" for example), even change the name of the registered base types (i know something of this can already be done, but i'm thinking more wisely) or suppress some of them (blocking the use of the floats/double type for examples).


    I hadn't thought that far, but of course, the concept can easily be extended to allow even further customization.



    Quote:

    - Pragmas to configure the engine (stack sizes for example) when script will be executed


    I'm not sure this fits with the design. But I'll keep it in mind for the future.

    Quote:

    - Bytecode optimizer: while browsing some time ago i've found another scripting engine out there that have an interesting feature, a bytecode optimizer... give it an eye, overall optimization could be even ~40% gain in execution speed ! (http://www.jewe.org/jewelscript/) anyway i don't mean to copy another project... -


    I already use bytecode optimization. :) And yes, it gives quite a lot of performance gain. There's still a lot that can be done in the optimizer though.

    I'll take a look at the implementation for jewelscript to see if I can get some new ideas (though I don't think so).

    ---

    Check my update to my original list. You'll find more answers to your suggestions/questions there.

    Thanks for the feedback.

    Share this post


    Link to post
    Share on other sites
    The only request that I have is that classes be handled like Java. Extend a class and implement an interface. For example:


    class B extends A
    {
    }

    // or

    class B implements C
    {
    }



    This will make your life easier and provide a familiar syntax. It also will kinda look like UnrealScript. ;)

    Share this post


    Link to post
    Share on other sites
    Guest Anonymous Poster
    I would love to see some basic support for contracts (pre/post conditions) being available in upcoming versions of AS, as mentioned in:
    http://sourceforge.net/tracker/index.php?func=detail&aid=1547663&group_id=161752&atid=821101


    Share this post


    Link to post
    Share on other sites
    Guest Anonymous Poster
    Quote:
    Original post by paradoxnj
    The only request that I have is that classes be handled like Java. Extend a class and implement an interface. For example:

    *** Source Snippet Removed ***

    This will make your life easier and provide a familiar syntax. It also will kinda look like UnrealScript. ;)


    check the thread: if engine properties are to be implemented in the fashion that kunitoki proposed above, then a request such as yours would become a runtime property setting-where users could easily specify which syntax shall be used to begin/end code blocks or implement inheritance.

    Share this post


    Link to post
    Share on other sites
    Deyja:

    I'll try not to. ;)

    paradoxnj:

    I don't know about this. Not that there is anything wrong with the Java style, but for something like this I'd rather stick as close to C++ as possible.

    Maybe in the future I can decouple the parser from the compiler, in a way that the syntax can be completely rewritten.

    AP:

    I don't quite understand the concept of contracts. I saw the post in SourceForge.net a couple of days ago, but haven't had a chance to respond yet.

    Would you mind giving me a brief overview of how it works? That would make my life a lot easier than if I have to go look for it on Google or something. My time is short as always.

    Share this post


    Link to post
    Share on other sites
    Quote:
    Original post by WitchLord
    Thanks for the compliments. Is there a link to your project anywhere, that we can check out, and I can link to?

    I'll check out the new standard draft. Thanks for the tip.

    Regards,
    Andreas


    The link that used to be up has been removed, but it existed only to be accessible by our professors anyway. I won't put it back up, because although it was one of the projects I've had the most fun with, it was still a school project, with little value to anyone else. It was a traffic simulator, with scripted behavior. Also, it's 45 MB due to the use of the bloated Windows Bitmap format ;-). Sorry, I don't mean to give you any excuses, but then again, why would I wanna lie.

    Good luck!

    Share this post


    Link to post
    Share on other sites
    Guest Anonymous Poster
    Basically, DbC means that your code may be associated with blocks that contain pre- and postconditions, that is the actual function body/code is ONLY executed if the precondition and postconditions match, so that programmers can ensure very well-defined behaviour for the code and basically guarantee that their code will only operate on data that it has been designed/conceived for, consider the following trivial example:


    int multiply_positives(int x,int y)
    {
    return x*y;
    }

    int multiply_negatives(int x,int y)
    {
    return x*y;
    }

    double divide(int a, int b)
    {
    return a/b;
    }

    int main()
    {
    multiply_positives(10,10);
    multiply_positives(10,-1); //oops: function was never intended to do that

    multiply_negatives(-1,-1);
    multiply_negatives(1,3); //

    divide(10,10); // okay
    divide(10,0); //not okay: division by zero

    return 0;
    }



    So programming languages that support "programming by contract" or "design by contract", allow programmers to define conditions that must be met in order to allow their code to be executed, and these conditions would be evaluated without anything in the actual code requiring to be executed first, so rather than an assert() or if in the code, contracts are separate.

    For example:

    int multiply_positives(int x,int y)
    precondition: x & y must be positive
    postcondition: return value must be positive

    int multiply_negatives(int x,int y)
    precondition: x & y must be negative
    postcondition: return value must be positive

    double divide(int a, int b)
    precondition: b != 0
    postcondition: none



    Anyway, that's pretty basic-the possibilities are pretty broad,the following wikipedia link should explain the concept much better than anything I might come up with: http://en.wikipedia.org/wiki/Programming_by_contract

    Share this post


    Link to post
    Share on other sites
    Guest Anonymous Poster
    and in C++ or rather a C++ oriented language it might look like:
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1773.html#function-pre-and-postconditions

    Share this post


    Link to post
    Share on other sites
    Todo:

    No worries. I was just curious. :)

    AP:

    Thanks for the brief explanation. I have a pretty good understanding of how it works now.

    It does seem like a lot of work to add this to AngelScript however, so while it might be useful, I won't implement it any time soon. At least not while there are other more useful features to be implemented first.

    I'll add it to the todo list anyway, so it won't be forgotten.

    Regards,
    Andreas

    Share this post


    Link to post
    Share on other sites
    Quote:

    I'll implement single inheritance for classes. Script classes will be able to inherit from other script classes, and also from specially registered application classes. It will not be possible to inherit from just any application registered class (at least I've not been able to think of any solution for that yet).

    why it would not be possible to register any application registered class ? i do not think that will be difficult, there was a patch posted here by Gilad that already addressed this stuff, even if simplified to the bone. if the problem is method invocation resolution i don't think is a real problem, just define a common way to resolve the correct function to execute when it could have the same declaration by traversing the object parent's registered methods/behaviours. or maybe the properties are the problem ?

    Quote:

    I don't think I'll implement multiple inheritance. The interfaces are already capable of handling most of the uses for multiple inheritance. Virtual inheritance most certainly wont be implemented, as that is a concept way too complicated and almost never used so it's just not worth it.

    i agree with multiple inheritance, even if i use it a lot and would like to get my hand on a script engine that allow me to do this (but remaining as simple and easy as angelscript). for virtual inheritance is somehow too complicated to have it correctly implemented...

    Share this post


    Link to post
    Share on other sites
    Maybe as I dig deeper into how inheritance will work, I may be able to find a solution to inherit from arbitrary registered C++ classes. But right now I believe it will cause a lot of trouble when the VM needs to determine the type of the object dynamically. Or when the script tries to pass a script derived class to a C++ function that expects the C++ class. We must also not forget the garbage collector.

    We'll see what happens in the future.

    Share this post


    Link to post
    Share on other sites
    you could implement it like this

    x bytes type identifier
    n bytes c++ class
    i bytes derivative class


    so if your call a class's c++ function your will operator on the n c++ bytes(this call convention

    all other script functions should be trivial to implement


    Share this post


    Link to post
    Share on other sites
    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"




    Share this post


    Link to post
    Share on other sites
    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 javascript 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

    Share this post


    Link to post
    Share on other sites
    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.

    Share this post


    Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    Sign in to follow this