Lars Gullik Bjønnes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 22, 2007 at 12:03:33AM +0200, Peter Kümmel wrote:
| > Lars Gullik Bjønnes wrote:
| > >Peter Kümmel <[EMAIL PROTECTED]> writes:
| > >
| > >| > As far as I can tell using QtCore in support/*.cpp is acceptable
| > >| > nowadays, so just use QProcess and be done.
| > >|
| > >| also mocing?
| > >
| > >Have I said lately that I really dislike Qt stuff outside Gui stuff?
| >
| > We don't have any advantage of having support Qt free.
|
| I am afraid this is a political or even religiuous debate, not a
| technical one.
if "lock-in" is technical or political is a debate of its own I guess.
I am not interested in the political aspect but using proven, maintained
technology in support enables us to:
- revive stagnant code: the situation WRT unicode was pretty much
stalled until Georg was brave enough to introduce QString and QFileInfo
helpers. Andre' is doing the same now with proper use of QFile here and
there instead of boost::fs.
- have shorter code: less code means easier to replace if we decide to.
- have simpler code: let us please recognize that Qt API is clean and
well thought out; in addition, most of the developers are already used
to Qt naming.
If we decide someday that Qt should be replaced by something else then,
provided that proper encapsulation is done in support, I am really
confident that there is absolutely *no* lock-in. We will just have to
rewrite part of support/*.cpp, that's all. The situation would be
exactly the same as with another library (libxml for example). As for
boost, it's usage is spread all over the source code and the real
technical lock-in is there IMHO. I like boost personally but, as long as
it is not a standard, we should not use it outside of support. And, no,
forecasting that part of boost will become a standard 20 years in the
future does not count :-)
Abdel.
