Inheritance

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Inheritance

Post by Kjell » Sat Sep 20, 2008 2:12 pm

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

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Sun Sep 21, 2008 3:06 pm

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!

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Sun Sep 21, 2008 3:43 pm

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

User avatar
diki
Posts: 140
Joined: Thu Sep 11, 2008 7:53 pm
Location: GMT+1
Contact:

Post by diki » Sun Sep 21, 2008 5:10 pm

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

User avatar
VilleK
Site Admin
Posts: 2052
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon Sep 22, 2008 3:04 pm

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.

User avatar
Rado1
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Thu Jul 29, 2010 8:39 pm

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.

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Thu Jul 29, 2010 9:21 pm

:)

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

User avatar
VilleK
Site Admin
Posts: 2052
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Fri Jul 30, 2010 6:50 am

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.

User avatar
Rado1
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Fri Jul 30, 2010 11:36 am

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.

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Fri Jul 30, 2010 12:14 pm

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 8)

K

User avatar
Rado1
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Fri Jul 30, 2010 12:36 pm

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.

User avatar
Kjell
Posts: 1721
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Fri Jul 30, 2010 12:48 pm

Oops,

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

K

User avatar
Rado1
Posts: 771
Joined: Wed May 05, 2010 12:16 pm

Post by Rado1 » Fri Jul 30, 2010 2:48 pm

Agreed.

User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski » Sat Jul 31, 2010 1:30 pm

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 ;)
iterationGAMES.com

User avatar
VilleK
Site Admin
Posts: 2052
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Sat Jul 31, 2010 2:37 pm

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

Post Reply