On Jul 3, 2010, at 10:02 PM, Krzysztof Kosiński wrote:
So what exactly is this "C++ification" intended to do? Syntax support for virtual functions is one of the main advantages of moving to C++.
I also thought the goal is to move off GObject for the SP tree, so rewriting functionality dependent on GObject should be part of the project.
Removal of GObject is going to be one of the last things we can do to our codebase. So much of it is dependent on the GTK/GObject approach, that it is a very large job to get there. Additionally the virtual function support is actually not nearly as much of an advantage as one might think, given that GTK/GObject already give us a fairly robust and mature object oriented framework. Other aspects of C++ bring much more benefit to our codebase (type safety, explicit casting, templates, etc).
Things are being approached in a cyclical iterative manner, with several other things happening in early passes. One of the first things to do is increase encapsulation and modularity while reducing extraneous cross-dependencies.
Moving random functions to be class members, making members private, etc. are all happening in the first pass. Basically that is the same work being done with GTK itself in their move to 3.x and going through and "sealing" members.
Basically this issue is very similar to that encountered with cleaning up the Y-axis inversion. On the surface it might seem like a very simple job. However once it gets looked into, the details stat to crop up all over that reveal the scope of work to be far more than one might initially guess. Getting that Y-axis cleaned up has been happening bit by bit over several years, and we're finally *close* to the point of being able to finish it.