interface MyInterface
{
void SomeFunction();
int AnotherFunction();
};
class A
{
A() {}
void FuncFromA() {}
};
class B : A, MyInterface // inherits from A, implements interface MyInterface
{
B() {}
FuncFromA() {} // overloads the function from class A
void SomeFunction() {} // implements the interface function
int AnotherFunction() {} // implements the interface function
};
void function()
{
B obj;
A a = obj; // OK, only the base class information is copied
MyInterface @i = obj; // OK, the handle for obj is taken, but interpreted as the interface
i.SomeFunction(); // Calls obj.SomeFunction();
obj.FuncFromA(); // Calls obj.FuncFromA() that overloads A.FuncFromA()
}
AngelScript - polymorphism, interfaces, and inheritance
I've finally decided the solution that I'll adopt for AngelScript in regards to script declared classes with inheritance, polymorphism, etc.
I will go the Java way, with only single inheritance and interfaces, as it is much easier to implement and get to work correctly. The C++ way that allow single, multiple, and virtual inheritance, is too complicated for the scripted environment.
The syntax will be similar to Java as well:
The application will be able to specify an interface that it expects, which will allow the scripts to declare classes that implements this interface and pass instances of that script class to the application function.
Normal C++ classes cannot implement the script interfaces, as they will simply not be compatible with the way AngelScript handles the interfaces. However, hopefully I'll be able to allow the application to implement C++ classes that inherits from an asCScriptObject class defined by the library, which can then be registered with the same functionality as the script declared classes. If all goes well the scripts will also be able to inherit from these special C++ classes.
I'm just telling you a bit about the near future of AngelScript, so that you can comment on it, and perhaps help me detect any flaws before I get too far into the implementation.
Regards,
Andreas
Will it differentiate between public, private, and protected inheritence?
Also, some random advice you're free to ignore, and I don't really know how to express the idea. I see that this can go two ways: you can implement just enough to allow us to extend polymorphic heirarchies in script, which I assume is what most people are going to want to do, or you can get horribly bogged down in making everything work perfectly. Angelscript is getting more and more powerful. I just want to remind you to remember what the library is for, and make it the best at that, instead of turning it into a general purpose language that's okay at everything but not great at anything.
Also, some random advice you're free to ignore, and I don't really know how to express the idea. I see that this can go two ways: you can implement just enough to allow us to extend polymorphic heirarchies in script, which I assume is what most people are going to want to do, or you can get horribly bogged down in making everything work perfectly. Angelscript is getting more and more powerful. I just want to remind you to remember what the library is for, and make it the best at that, instead of turning it into a general purpose language that's okay at everything but not great at anything.
To start with everything will be public, but if it becomes necessary in the future, adding this access restriction should be a rather simple matter.
I agree with you on being careful with turning AngelScript into a general purpose language, with only okay results. I certainly do not want to do that, and please let me know if you think that I'm going too far with the features.
I feel that classes without polymorphism are quite useless, so the interfaces are a necessary feature. Inheritance is less important, in my opinion, since you're usually not writing huge projects in scripts and can in most cases simply duplicate the necessary code. Single inheritance is almost free though, so I decided to support that. Multiple inheritance, and even more so virtual inheritance, is much more complicated and expensive. With the current design they are not even possible to implement, which is one more reason why I decided to go with Java way.
Regards,
Andreas
I agree with you on being careful with turning AngelScript into a general purpose language, with only okay results. I certainly do not want to do that, and please let me know if you think that I'm going too far with the features.
I feel that classes without polymorphism are quite useless, so the interfaces are a necessary feature. Inheritance is less important, in my opinion, since you're usually not writing huge projects in scripts and can in most cases simply duplicate the necessary code. Single inheritance is almost free though, so I decided to support that. Multiple inheritance, and even more so virtual inheritance, is much more complicated and expensive. With the current design they are not even possible to implement, which is one more reason why I decided to go with Java way.
Regards,
Andreas
Hi Andreas,
I think the classes are great since they make many things easier. Inheritance is also OK. But I personally don't need polymorphism or interfaces. I'm also a little bit concerned that that might be a little bit to much for a scripting language. I just think that sometimes less is more and one of the big strengths of AngleScript is that the library is so light weight. But that's just my opinion so please don't take it to serious.
By,
Martin
I think the classes are great since they make many things easier. Inheritance is also OK. But I personally don't need polymorphism or interfaces. I'm also a little bit concerned that that might be a little bit to much for a scripting language. I just think that sometimes less is more and one of the big strengths of AngleScript is that the library is so light weight. But that's just my opinion so please don't take it to serious.
By,
Martin
I have to disagree with Cheetah3D.. polymorphism can be a really helpful tool. Consider the scenario where enemy entities are defined in scripts: enemies could be implemented by deriving from a common enemy class and implementing different behaviours.
I'm not saying this is the only way to do this - given the dynamic nature of scripting, one can easily map different scripts to each enemy type with, say, a set of functions with different implementations and I would probably adopt the latter approach to keep things simple.
I do agree however that polymorphism may be too complex a notion for level designers, despite being a neat solution. Having said that, there are other scenarios that justify the existense of polymorphism in a script and in some cases may be the most feasible approach.
I'm not saying this is the only way to do this - given the dynamic nature of scripting, one can easily map different scripts to each enemy type with, say, a set of functions with different implementations and I would probably adopt the latter approach to keep things simple.
I do agree however that polymorphism may be too complex a notion for level designers, despite being a neat solution. Having said that, there are other scenarios that justify the existense of polymorphism in a script and in some cases may be the most feasible approach.
Don't worry people, the inheritance and interfaces shouldn't add too much overhead for AngelScript, and while they are not always needed, they really can be a great tool for simplifying the programming tasks.
AngelScript will continue to be light-weight, but it should also be flexible enough to let the application developer solve his problems in the way he feels most comfortable, whether that be through using only global functions, or classes with polymorphism.
I have plans to use compile time flags for disabling support for various features, in order to allow the application to use an even more light-weight version of AngelScript. Though, this in itself can be difficult to do, so we'll have to wait and see how well this works.
Regards,
Andreas
AngelScript will continue to be light-weight, but it should also be flexible enough to let the application developer solve his problems in the way he feels most comfortable, whether that be through using only global functions, or classes with polymorphism.
I have plans to use compile time flags for disabling support for various features, in order to allow the application to use an even more light-weight version of AngelScript. Though, this in itself can be difficult to do, so we'll have to wait and see how well this works.
Regards,
Andreas
Just wondering, can a method be non-virtual? And if so, can someone please explain when that is wanted/needed/useful? I've always thought polymorphism was what made OO so powerful..
You do not want all of your methods to be virtual as there is a certain cost in looking up the function address from the vtable.
You don't always need all of your objects to be polymorphic either.
You don't always need all of your objects to be polymorphic either.
If you're using inheritance, I cannot think of any reason why you wouldn't want to use virtual methods. But as Rain Dog said, virtual methods have a slight performance overhead, so if you don't need them, you shouldn't use them.
However, I'm not sure if I'll use non-virtual methods in AngelScript yet. I do not think the overhead that virtual methods incurr will be noticeable in the script language. If I can do without the non-virtual methods, the language will be cleaner and less confusing for script developers. But we'll see about this in the future.
Regards,
Andreas
However, I'm not sure if I'll use non-virtual methods in AngelScript yet. I do not think the overhead that virtual methods incurr will be noticeable in the script language. If I can do without the non-virtual methods, the language will be cleaner and less confusing for script developers. But we'll see about this in the future.
Regards,
Andreas
Non virtual functions have different lookup rules, for one thing. Examine the following example...
class A{ public: virtual void foo() {} void bar() {}};class B : public A{public: virtual void foo() {} void bar() {}};A* an_a = new A();an_a->foo(); //calls A::fooan_a->bar(); //calls A::barB* a_b = new B();a_b->foo(); //calls B::fooa_b->bar(); //calls B::bar (or it might actually be an ambigous...)an_a = a_b; //implicit downcastan_a->foo(); //calls B::fooan_a->bar(); //calls A::barThis topic is closed to new replies.
Advertisement
Popular Topics
Advertisement