Deriving classes??
by Markus Nuebel · in Torque Game Engine · 02/22/2004 (11:32 pm) · 5 replies
Hi all.
Having worked with different kinds of SDKs so far, I am used to derive my own classes, and overwrite base class methods, whenever I want to change the functionality of a SDK method.
This way way I keep my implementations in separate files and can benefit from upgrades to SDK classes.
(I just have to upgrade the SDK and check my code, if it still works)
This does not seem to work with torque.
Most of the members of engine classes are private and have no getter/setter methods for external access.
Changing base class functionality is nearly impossible this way.
I tried it by doing subclasses of trigger and player, but failed, due to missing access to members of the base classes.
I don't understand why torque relies so heavily on private stuff. Since it is a C++ engine and also called an SDK, it could be so easy, to do your customization in derived classes.
Instead I have to change engine classes directly, which normally causes problems later on, when merging with updates.
I think it is a good idea, to have GG change most of their members from private to protected. At least for all stuff located in the /game folder.
This a part of the engine, where it is most likely to customize stuff.
-- Markus
Having worked with different kinds of SDKs so far, I am used to derive my own classes, and overwrite base class methods, whenever I want to change the functionality of a SDK method.
This way way I keep my implementations in separate files and can benefit from upgrades to SDK classes.
(I just have to upgrade the SDK and check my code, if it still works)
This does not seem to work with torque.
Most of the members of engine classes are private and have no getter/setter methods for external access.
Changing base class functionality is nearly impossible this way.
I tried it by doing subclasses of trigger and player, but failed, due to missing access to members of the base classes.
I don't understand why torque relies so heavily on private stuff. Since it is a C++ engine and also called an SDK, it could be so easy, to do your customization in derived classes.
Instead I have to change engine classes directly, which normally causes problems later on, when merging with updates.
I think it is a good idea, to have GG change most of their members from private to protected. At least for all stuff located in the /game folder.
This a part of the engine, where it is most likely to customize stuff.
-- Markus
About the author
#2
For many compilers just add something like -Dprivate=protected (/D for the MS compiler) to command line of the compiler driver (somewhere in the makefile or the IDE). Compiler environments generally have multiple mechanisms for defining preprocessor macros, so it might be even easier to define this in an environment variable if your preprocessor picks up macros from there, because then you have no difference to manage between your files and the CVS repository.
Access control in C++ is a compile-time mechanism, so can be defeated handily by preprocessor tricks. (Luckily this isn't Java, which encodes access control in the bytecode files, and has no preprocessor.)
02/23/2004 (11:44 am)
Just use a macro to define private as protected.For many compilers just add something like -Dprivate=protected (/D for the MS compiler) to command line of the compiler driver (somewhere in the makefile or the IDE). Compiler environments generally have multiple mechanisms for defining preprocessor macros, so it might be even easier to define this in an environment variable if your preprocessor picks up macros from there, because then you have no difference to manage between your files and the CVS repository.
Access control in C++ is a compile-time mechanism, so can be defeated handily by preprocessor tricks. (Luckily this isn't Java, which encodes access control in the bytecode files, and has no preprocessor.)
#3
Yes, you are right, there are ways around this problem. Some more some less painfull.
I will change the private to protected declarations, where I need them, because this should be only a minor issue, when doing a merge.
But in the long term I would like to see GG work on this issue for all the classes in the /game folder.
Just because it allows people to submit new stuff, that can be integrated more easy.
One example:
For realmwars I am wroking on a LadderZone implementation. I wanted the LadderZone to be a subclass of trigger, because it inherits most of the trigger functionality, but has it's special cases, like switching movement behavior on the player and stuff like that.
This was impossible to do because of too many private members (or missing getter/setters) in trigger. So I did a copy of trigger, and did my changes in there.
In my opinion, this is overkill, since trigger is a more or less heavy class and I only have to do changes to a few places. And I don't think that it is elegant to copy a whole C++ class, while there is inheritance in the language.
Having made the switch from private to protected would causes the RealmWars engine code to differ even more from the current torque engine code.
(And having done the merge of RealmWars with current Torque HEAD, I must say, that it is even now a real pain ;) )
I don't want to raise an issue here, but I think the whole comunity would benefit, because it would be easier for people to contribute additions, enhancements and stuff like that, if the don't have to submitt changes to existing classes.
Simply submit a derived class. People can use it or not and it is very unlikely that such a class will break existing functionality, because the bases are untouched.
-- Markus
02/24/2004 (12:39 am)
Thanks for the feedback guys.Yes, you are right, there are ways around this problem. Some more some less painfull.
I will change the private to protected declarations, where I need them, because this should be only a minor issue, when doing a merge.
But in the long term I would like to see GG work on this issue for all the classes in the /game folder.
Just because it allows people to submit new stuff, that can be integrated more easy.
One example:
For realmwars I am wroking on a LadderZone implementation. I wanted the LadderZone to be a subclass of trigger, because it inherits most of the trigger functionality, but has it's special cases, like switching movement behavior on the player and stuff like that.
This was impossible to do because of too many private members (or missing getter/setters) in trigger. So I did a copy of trigger, and did my changes in there.
In my opinion, this is overkill, since trigger is a more or less heavy class and I only have to do changes to a few places. And I don't think that it is elegant to copy a whole C++ class, while there is inheritance in the language.
Having made the switch from private to protected would causes the RealmWars engine code to differ even more from the current torque engine code.
(And having done the merge of RealmWars with current Torque HEAD, I must say, that it is even now a real pain ;) )
I don't want to raise an issue here, but I think the whole comunity would benefit, because it would be easier for people to contribute additions, enhancements and stuff like that, if the don't have to submitt changes to existing classes.
Simply submit a derived class. People can use it or not and it is very unlikely that such a class will break existing functionality, because the bases are untouched.
-- Markus
#4
But I fear it's low enough on the list it's not going to get touched for a while. There's just too much important stuff to do, and too little time to do it in. ;)
02/24/2004 (10:03 pm)
Markus - you're completely right, and we acknowledge that something like this is needed, at the very least to make it easier to distribute code-based content packs.But I fear it's low enough on the list it's not going to get touched for a while. There's just too much important stuff to do, and too little time to do it in. ;)
Associate Kyle Carter
Although I generally haven't had too much trouble extending stuff. Really, you're going to be branching your project off of HEAD into your own repository, then doing occasional merges from HEAD, so having to change access levels shouldn't be a bg deal.
Perhaps someday we'll get everything cleaned up. :) Though I will point out that having a load of virtual methods for accessors would be a bit painful. ShapeBase is already bad enough...