Nestharus
o-o
- Reaction score
- 84
Just wanted to respond to this post-
http://www.thehelper.net/forums/showpost.php?p=1152569&postcount=11
and as this is a completely different topic, I believe a thread is much more appropriate ^_-.
Themis, I used to think about making a system like that myself . In fact, I even released it a long time ago and it actually worked, lol. The issue here is when you start doing systems that can handle all types and do all of this stuff, you have to sacrifice a lot for the ambiguity of the code. For example, using triggers to handle types, equations, this, that, and the other thing ><. You also end up having to use hashtables in the background to store references and records to various lists. All in all, the entire design becomes very sluggish and it would never be used in a good map. It might be used to quickly make something, but considering the complexities and power of such a system, I doubt it'd be even used for that.
Systems need to be type specific and need to handle very specific needs. About the lowest you can go for data structures is linked lists, stacks, queues, indexed arrays, etc . You can't make a system that handles relationships between unknown data structures and stores records of all of these relationships-
attaching var a and b to var c
attaching var a and b to var d
attaching var d to var f
etc
transferring an instance of a to f
Maintaining order of all of the above as well ><.
Do you know why you can't maintain records of all of these relationships? If you try to handle relationships that you know nothing about, you have to use methods that slow down the entire code. The code is always better written when you know what you are handling. Look at reflection in C# ><. Have any idea how slow that is? Lol.
A good rule of thumb is to only write code for stuff where you know what you are handling. If you write code for stuff that you know nothing about, then it just gives you a headache and gives people using it a headache.
The next good rule of thumb is to minimize coupling and maximize cohesion.
What this means is that you don't write code that has to be used in a very specific way (things using it then have to have a lot of work put into them to use it and maintainability over the entire map dies).
While making a system that can do everything etc can increase maintainability dramatically (you never have to make any new code, all code handles all types), the problem again is that the methods used kill your map. Would you write a projectile system using this enormous system of your friend's? I know I wouldn't write a projectile system with my AGL-T3 (previously Spawn). Why? A projectile system written for the specific unit type would be 30x faster.
While these huge systems can be like feats of accomplishments (making one piece of code work for 30 types or attaching data no matter what it is etc and having your system handle it and gets its properties like x and y coordinates no matter what it is), they kill on speed. Polymorphism can be a good thing, but it can also be a bad thing.
This is the reason why I myself put a lot more effort into developing collections for JASS rather than continuing my AGL project. Collections can be used in any situation, but they don't handle the relationships.
Don't do too much, otherwise the entire thing fails . This is a lesson I've been learning for the last year ;p.
Btw, my AGL was a highly sophisticated hasthable/trigger system. Last version I did was 2000 lines and the newest version would have been 3000. There's a reason I stopped working on it ; ).
http://www.thehelper.net/forums/showpost.php?p=1152569&postcount=11
and as this is a completely different topic, I believe a thread is much more appropriate ^_-.
Themis, I used to think about making a system like that myself . In fact, I even released it a long time ago and it actually worked, lol. The issue here is when you start doing systems that can handle all types and do all of this stuff, you have to sacrifice a lot for the ambiguity of the code. For example, using triggers to handle types, equations, this, that, and the other thing ><. You also end up having to use hashtables in the background to store references and records to various lists. All in all, the entire design becomes very sluggish and it would never be used in a good map. It might be used to quickly make something, but considering the complexities and power of such a system, I doubt it'd be even used for that.
Systems need to be type specific and need to handle very specific needs. About the lowest you can go for data structures is linked lists, stacks, queues, indexed arrays, etc . You can't make a system that handles relationships between unknown data structures and stores records of all of these relationships-
attaching var a and b to var c
attaching var a and b to var d
attaching var d to var f
etc
transferring an instance of a to f
Maintaining order of all of the above as well ><.
Do you know why you can't maintain records of all of these relationships? If you try to handle relationships that you know nothing about, you have to use methods that slow down the entire code. The code is always better written when you know what you are handling. Look at reflection in C# ><. Have any idea how slow that is? Lol.
A good rule of thumb is to only write code for stuff where you know what you are handling. If you write code for stuff that you know nothing about, then it just gives you a headache and gives people using it a headache.
The next good rule of thumb is to minimize coupling and maximize cohesion.
What this means is that you don't write code that has to be used in a very specific way (things using it then have to have a lot of work put into them to use it and maintainability over the entire map dies).
While making a system that can do everything etc can increase maintainability dramatically (you never have to make any new code, all code handles all types), the problem again is that the methods used kill your map. Would you write a projectile system using this enormous system of your friend's? I know I wouldn't write a projectile system with my AGL-T3 (previously Spawn). Why? A projectile system written for the specific unit type would be 30x faster.
While these huge systems can be like feats of accomplishments (making one piece of code work for 30 types or attaching data no matter what it is etc and having your system handle it and gets its properties like x and y coordinates no matter what it is), they kill on speed. Polymorphism can be a good thing, but it can also be a bad thing.
This is the reason why I myself put a lot more effort into developing collections for JASS rather than continuing my AGL project. Collections can be used in any situation, but they don't handle the relationships.
Don't do too much, otherwise the entire thing fails . This is a lesson I've been learning for the last year ;p.
Btw, my AGL was a highly sophisticated hasthable/trigger system. Last version I did was 2000 lines and the newest version would have been 3000. There's a reason I stopped working on it ; ).