[Qt-interest] Qt-interest Digest, Vol 15, Issue 148

Oliver.Knoll at comit.ch Oliver.Knoll at comit.ch
Wed Feb 17 12:33:07 CET 2010


Thiago Macieira wrote on Tuesday, February 16, 2010 10:53 PM:

> ... 
> So, yes, I will continue to recommend QXmlStreamReader because it's
> more efficient and I believe it's the future. You may disagree with
> me.  

In another thread I read the recommendation (I think it was even from you, Thiago), that one should prefer QNetworkAccessManager.html over QFtp, for example. I know that this information is also spread across the Qt documentation, but maybe a general "Recommended classes (which will replace this and that)" would be helpful. Maybe even with an "inofficial character" (e.g. not "legally binding ;), linked on http://labs.trolltech.com/blogs/, so people would know in which classes the most effort is put in, and which classes are likely to be abandoned in the next major release.

I must say that I am also using QDomDocument and Co, simply because my XML is rather small (so performance is not a major issue for me) and I still think QDomDocument is rather convenient to use.

On the other hand I am a big fan of abandoning old techniques when it comes to major releases (3 to 4, 4 to 5 etc.). Don't keep old code which is not well working lying around for compatibility issues, especially if there is a better class/approach which does the same, but better! Even if that means I have to adapt my own code! Keep the API clean and lean, don't be afraid to throw away stuff! "Evolving code" is good - (if it doesn't happen all too often, and as Thiago pointed out, there are still a couple of years ahead until the next major Qt release).

And yes, I *did* live through the changes of a commercial product which went from Qt 3 to 4, and thanks to the excellent Qt "migration" documentation there *was* a lot of work (to really get rid of the last "Qt3Support" class), but it was rather "just work, just minor problems" - rather "mechanical".

And in the long term that does only good to a toolkit, because fewer classes also mean fewer documentation to read and understand, fewer classes to support etc.

So if the Trolls (sorry, but "the Nokians" still just sound silly to me ;) think that QXmlStreamReader deserves more love than QDom, then be it! In the past I think most changes improved the Qt toolkit a lot, so I do trust them on these kind of decisions!


May I quote here my professor (he quoted someone else, too, so he might forgive me): "Make it as simple as possible, but not simpler!"

:-)

Cheers, Oliver
-- 
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22



More information about the Qt-interest-old mailing list