Linked by Quentin Hartman on Mon 14th Jul 2008 08:46 UTC, submitted by makkus
At last week's Guadec meeting, Kristian Rietveld delivered the GTK+ "state of the union" report. GTK+ is the multi-platform toolkit behind a number of popular applications and, perhaps most well known, the Gnome Desktop environment for Linux. Read the full report here.
Permalink for comment 322774
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-01-02
It's good to see so much activity in the GTK+ area, but something really disturbed me: the item they mention the most for GTK+3 is making structure fields private i.e. the app uses only accessor functions and not directly the member data fields in structures.
Of course this is a very good idea -- in fact it is more than that -- it is vital in any object-oriented framework. Indeed, if structure fields are publically exposed to apps, then it is impossible to rework them internally without breaking these apps. Which often makes implementation changes impossible.
So what really disturbs me is that GTK+ somehow manage to make it into year 2008 with publich structure fields. Then again, the C language doesn't help them at all with making these private... since it wasn't designed for object-oriented programming in the first place.
In my humble opinion this is yet another example that object-oriented programming in C is a bad idea and that when you start doing this, it is more than time to start using C++... in fact I can hardly remember the reason why GTK and GNOME still refuse to use at least some features from C++. The two arguments mentioned are a) "C++ libraries are harder to make bindings for" and b) "C++ doesn't have a standard ABI". Well, as has often been said, these arguments are not convincing: a) there exists Qt bindings to a plethora of languages, and b) since each released distro sticks to one compiler version (like "gcc 4.2.3") it doesn't matter if the C++ ABI is not always preserved across versions.