ZGameEditor forum

Hi,

A inheritance / extends property for Models combined with a Class Component would come in handy when constructing various models that share a number of Variables and Behaviors.

K

i agree; but care must be taken in the way this is implemented. since a model could inherit from more than one other model, it might clutter the interface when implemented as drop-down options. i also would not know where / in which way this would be implemented logically (a 'class' component maybe? a 'heritage' property tree on the model itself?). but a very interesting & potent thing to think about!

Hi diki,

Since most / all? programming languages limit the amount of Classes you can Extend from to 1, you probably want to stick to that number. You could however enable extending Classes themselves as well, in a classic "Model" > "Ball" > "Soccer Ball" type of fashion.

K

hm, i guess you are right. don't know where i got that idea from ... makes sense, of course.

In GameMaker (GM) you can set a "parent" object on objects (object in GM is like a ZGE Model). So if you have a "Enemy"-object which all enemies inherits from you can save time by defining collisions against "Enemy" instead of having to add a collision for every single enemy-type.

I agree such a feature would be useful in ZGE for sharing definitions and behavior between models. I just need to find a way of implementing it, I haven't given it much thought yet so I don't know if it is difficult or not.

Inheritance is very handy mechanism in OO languages, but it can bring conceptual complications and probably would make the code more complicated in ZGE. Some questions: what are the inherited features (properties and/or whole tree sections?), how to extend and override inherited features, is it possible to have "unspecified" value for properties you must specify in children or you want to inherit from parents, what about visibility (private/protected; does it make sense?), etc. ?

Instead of inheritance I suggest a simpler mechanism - importing/inclusion of components:

For groups: A new component GroupImport would represent inclusion of the content of the referred group at the place of GroupImport's occurrence.

For any component: To generalize this concept, inclusion of any (named) component (including group) would be allowed; by means of new ComponentImport component. Of course if implemented this, GroupImport is useless.

With component import you can achieve an interesting level of reusability but also clear extensibility of shared code. In addition, you do not need to change existing components and do not need to specify new mechanism of inheritance.

Thing is, ZGE already has inheritance ( ModelState ), it's just limited to one level right now. If a ModelState would have a States node as well, there wouldn't be a problem ..

.. apart from the fact that you can't spawn a ModelState*. In order to solve that you really need a Inheritance property ( selecting the Model to inherit from ).

*Which is already a problem right now. When you have a Fruit Model with Apple + Banana + Orange ModelStates, you need to spawn a Fruit Model and switch it to the desired fruit in the OnSpawn event.

K

I believe that if the type-system was improved (as suggested in other feature requests) then the issue of inheritance would not be as important.

For instance if you had a ZLibrary with functions that could take a Model (or a user defined type such as PlayerModel) as a parameter then code could be shared that way.

ComponentImport is still a good idea though. I envision this could be used to "call" a complex OnRender-set of components that you don't want to have a copy of in every Model because that would make it harder to change.

Kjell wrote:Thing is, ZGE already has inheritance ( ModelState ), it's just limited to one level right now. If a ModelState would have a States node as well, there wouldn't be a problem ..

Hmmm... I never thought of ModelState as the mechanism of inheritance... but you are right, it has some features of OO inheritance I did not realize before... interesting Several other features of OO inheritance (e.g. different kinds of polymorphism) are missing.

In addition to the problems you mentioned, there is also restricted extensibility/usage of parent list tree items (OnRender, OnUpdate, etc.). The Model's list tree items are executed as first, then ModelState's list tree items. There is no possibility to call the parent's code from specific place of the children code (e.g. to execute child's before parent's code); similarly to usage of 'super' in Java. With ComponentImport it would be possible.

Furthermore, you can include one (part of) code (e.g. OnRender) from one Model and another one (e.g. OnUpdate) from another Model. With ComponentImport you can also achieve a simple (naive) form of aspect programming; the code relevant to some aspect is placed in a separate Group and then included to all models having this aspect. Overall code reusability can be improved if used properly.

Hi Rado1,

You don't have to convince me, I'm all for the "ComponentImport" idea I just see that separate from the inheritance thing .. even though they do address some of the same problems.

Not entirely sure about the name though. Since I imagine it'd behave somewhat like a subroutine, perhaps CallComponent would be more appropriate? Being able to Call / Import Group Components ( and thus all its children ) would be great

K

Hi Kjell,

you are absolutely right! These two mechanisms are different and just address the problem of sharing code.

I'm fine also with CallComponent. (The subrutine analogy is not very precise - subrutines are explicit constructs of programming languages and have parameters. But this is not important here anyway.)

Rado1.

Oops,

Referring to the system stack or jump / return operations would have been more accurate yes In any case, something that happens at run-time, not at compile-time.

K

Agreed.

I really like Rado1's idea with Kjells name "CallComponent",. would be very usefull, in many situations.

Inheritance seems like another very usefull feature although how it would work does confuse me some.., StateStates I could use though

I attempted this and found a problem. Say if BananaModel.OnRender do a CallComponent on FruitRenderGroup. Then ZExpressions in FruitRenderGroup that use "CurrentModel" will still refer to whichever model FruitRenderGroup is defined in. This is a weakness of the scripting engine, CurrentModel should be a function which always returns the model currently executing instead of referring to where it is defined.

Anyway apart from that problem it works fine so here it is if you want to try it out. Perhaps it can still be usable?

http://www.zgameeditor.org/files/ZGameEditor_beta.zip