I'm no expert in c/c++ code but here it goes.
When one is playing this game, one clearly see that much of its identities are objects. I mean, they are physical objects: they have properties, actions, interactions with other objects, receive orders, Join a group, are built and destroyed, etc. All this "things", one must admit, are today better implemented in a objected oriented paradigm, where methods, friends, virtual methods, private and public domains, polymorphism, overloading etc. do each job.
By better implemented, I mean that the code is:
- better portable;
- better readable;
- better debugged;
- better expandable;
- same or no relevant computational cost;
The question, I think, is not whether this code should or should not be ported. In my point of view, the 1º question (and the 2º most difficult to answer right now) is: how can we port this old, yet so great and so tested code to C++. How can we find a intelligent way of porting it.
I've been studied the code, and without doubt, it is a difficult task!, I think that anyone (so as the devs) who know some (or most) of the code, understand this problem. And this is, in my perspective, the reason why there is the inertia to change a so good coded wz code to C++.
There is a great risk that a bad port can cause some good months of debugging (that was already made on the current code) with the increased possibility of abandoning the project (of porting), which can causes months (and a lot of code wasted) of delay in the current tasks of maintaining the current code. In my perspective, people like Seismo haven't yet understood (or don't want to understand) this pertinent point.
To test a port, I personally wasted 1 day of my life trying to only port the group.h/cpp to a class, and I must assume is difficult: either the design options, my ignorance, or simply the fact that the rest of the code is not ported yet and so a lot of things just don't fit well. (And I'm so noob that I deleted the local repository where it was stored ahahahahahahaha).
In my opinion, the conclusion of the test was this: it is possible to port, but this will cause some very nasty stuff in the current project. I perceive that a port means a whole new bug system would have to be built from scratch, basically because the current one is based on the current code paradigm, that would change with the port. Probably some of the things had to be built too, but I don't know enough of this code to tell you about.
So, this leads to my 2º question (and the 1º most difficult to answer right now): is it worth?
I personally don't know the answer, but I have some opinion:
In a long term objective, it is fundamental to port it:
- The better implemented the code, the more devs came to join, which is good for the community;
- The faster is to debug which means faster response to bugs, which means more people playing the game, which is good for the community;
- Portability for obvious reasons;
- Better expandable which means more features/year, which means more people joining the community, which is good for the community.
- This is a open source community, and so, one of it the objectives, by definition, is to be a community, which means that, by definition, have different points of view;
- One don't know how to quantify the concept of "long term objective", because different people have different definitions of long;
- Some people(developers) spent much time working on this code, and an abrupt change on it is, by its definitions, a shake to them. If the change goes wrong, the developers are (again by definition) the best targets to blame, which can in turn leads to some bad environment on the community, which is bad for the community.
- Most people (who play games) don't care about all of this; they only want a good, stable, low bug game to play. A complete stop to code maintenance makes people leave the game (and the community).
Have all said for now,