Jump to content
  • Advertisement
Sign in to follow this  
p_k

AngelScript - single inheritance model

This topic is 3042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This thread should be dedicated to extending AngelScript by single-inheritance model that can be exposed by the C++ classes. Currently there is no such way how to tell AngelScript that two classes are related. This is quite problem, because component-based frameworks always uses base-classes and classes that extends them. Single-inheritance model is good enough to implement this.

Currently I'm seeing this as the biggest weakness of AngelScript library.

Implementation:
- Each class need to have baseTypeId
- Engine must allow to call members of component A that extends from component B from the type of component B (this should be already done, because AS supports inheritance for classes declared by the script).

As author said in different thread that C++ inheritance model is very complicated. You can base class on two or more other classes and there is possibility for virtual inheritance. I completelly agree and I think that this should't be supported. This is just medicine to support inheritance model found in 99.9% applications and to expose it to the scripting environment.

I'd like to hear from the AS author what is needed to add support for it and if he accepts my proposal. I really think that this is needed feature and I'm unable to expose API into scriptable environment without it. I'd like to add some features into AS myself (jit-compiler), but this can't happen if AS will be not suitable (and choosen) as a scripting environment for my library.

Thanks!

Share this post


Link to post
Share on other sites
Advertisement
Of course you can register class hierarchies even without this change, it just requires a little more work.

I would gladly add support for inheritance to the registered types.

The first step would be to add a parameter to RegisterObjectType that allow you to give the base class.

The asCObjectType already has a member: derivedFrom, that should be used to store the base class (this one is already used for single inheritance for the script classes).

The second step would be to have all the methods and properties copied from the base class to the new class.

The last step would be to automatically register the reference cast behaviours for both base class and derived class. The behaviour would just be a dummy function that returns the same pointer.


It would be necessary to find a way to prevent the developer from registering a class where the base class is not the first, because the properties and the reference cast behaviours won't work and will most likely cause difficult to find bugs in the application.

Share this post


Link to post
Share on other sites
Quote:

Of course you can register class hierarchies even without this change, it just requires a little more work.


Sorry, for me this is workaround I would like to avoid. The engine should know about relations and should call base class members without this.

Quote:

I would gladly add support for inheritance to the registered types.

The first step would be to add a parameter to RegisterObjectType that allow you to give the base class.


Yeah! I think that this is correct way.

Quote:

The asCObjectType already has a member: derivedFrom, that should be used to store the base class (this one is already used for single inheritance for the script classes).


Ok.

Quote:

The second step would be to have all the methods and properties copied from the base class to the new class.


I really don't understand this step. If scripting engine knows about base class why you want to copy base class members to derived one? Shouldn't be this done by the engine itself? Is there some limitation in engine that prevents from doing this?

For me this means that if I wrote huge base class (for example 200 members) and 20 derived classes then AngelScript duplicate 6000 methods.

Quote:

The last step would be to automatically register the reference cast behaviours for both base class and derived class. The behaviour would just be a dummy function that returns the same pointer.


I think that casting from derived class to base class should be automatic. Casting from base class to derive class should be controllable (I really like the solution that I can do the cast in C/C++, because I'm not using RTTI for example).

Quote:

It would be necessary to find a way to prevent the developer from registering a class where the base class is not the first, because the properties and the reference cast behaviours won't work and will most likely cause difficult to find bugs in the application.


Really big red warning in the documentation;-)

Share this post


Link to post
Share on other sites
Quote:
Original post by p_k
I really don't understand this step. If scripting engine knows about base class why you want to copy base class members to derived one? Shouldn't be this done by the engine itself? Is there some limitation in engine that prevents from doing this?

For me this means that if I wrote huge base class (for example 200 members) and 20 derived classes then AngelScript duplicate 6000 methods.


You're correct, but this is currently how it works. If you want to reduce the memory consumption then you'll have to make a lot more changes, probably both to the compiler, the VM, and the class that saves/loads bytecodes.

Let's take it one step at a time.

Quote:
Original post by p_k
I think that casting from derived class to base class should be automatic. Casting from base class to derive class should be controllable (I really like the solution that I can do the cast in C/C++, because I'm not using RTTI for example).


It will be as you say. The cast from the derived class to base class should use the asBEHAVE_IMPLICIT_REF_CAST behaviour, and the cast from the base class to the derived class should use the asBEHAVE_REF_CAST behaviour.

Again, as a future improvement, the compiler could know about the relationship directly just as it does for the script classes.


Quote:
Original post by p_k
Really big red warning in the documentation;-)


It doesn't work. People barely read the manual as it is. The library must definitely do all that is possible to avoid misuse.

Share this post


Link to post
Share on other sites
Quote:

You're correct, but this is currently how it works. If you want to reduce the memory consumption then you'll have to make a lot more changes, probably both to the compiler, the VM, and the class that saves/loads bytecodes.


Can you sumarize what is needed somewhere so I can read it and try to do it myself? For me it's currently hard to contribute to your code, I'm not familiar how it works.

BTW: What is your optinion about contributions, is angelscript SVN (or other VCS) accessible somewhere, can I create for example my branch so you can review my changes?

Quote:

Again, as a future improvement, the compiler could know about the relationship directly just as it does for the script classes.


I think this would be cool.

Quote:

It doesn't work. People barely read the manual as it is. The library must definitely do all that is possible to avoid misuse.


It was joke;)

I think that person who is using C++ should have some basic knowledge about it. Currently I don't know how to detect developer mistakes, maybe asserts, but definitelly some way that will not pollute release builds.

Share this post


Link to post
Share on other sites
Quote:
Original post by p_k
Quote:

You're correct, but this is currently how it works. If you want to reduce the memory consumption then you'll have to make a lot more changes, probably both to the compiler, the VM, and the class that saves/loads bytecodes.


Can you sumarize what is needed somewhere so I can read it and try to do it myself? For me it's currently hard to contribute to your code, I'm not familiar how it works.


To implement the piece of code that copies the properties and methods from the base class you can take a look at the method asCBuilder::CompileClass, especially the loop between lines 1587 and 1708. This is the code that implements the inheritance for script classes.

You should create a method in the asCScriptEngine with this implementation and have it called from the RegisterObjectType when a type is registered with a base class.

The automatic registration of the reference cast behaviours can be done by calling the actual RegisterObjectBehaviour, so you don't have to redo that.

Once you have this working, we can see what optimizations and improvements that can be done. I would have to investigate this in order to give you a overview as to what would have to be modified, and I don't have the time to do that investigation at the moment.




Quote:
Original post by p_k
BTW: What is your optinion about contributions, is angelscript SVN (or other VCS) accessible somewhere, can I create for example my branch so you can review my changes?


AngelScript is in a SourceForge.net SVN (link at the wip page). You don't need a branch in the SVN. Just send me the modified files and I'll check the changes with WinMerge.





Quote:
Original post by p_k
I think that person who is using C++ should have some basic knowledge about it. Currently I don't know how to detect developer mistakes, maybe asserts, but definitelly some way that will not pollute release builds.



Asserts are enough. Having a templated function do a cast from derived class to base class and then comparing if the pointers are the same should be enough to verify that the inheritance will work. Of course, this would require a class instance. I've read an article that does a check like this without an actual class instance, I'll see if I can find that again.


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!