[Qt-interest] The argument for Qt

[Rui Maciel]

Thiago Macieira wrote:

> On Thursday, 20 de October de 2011 20:41:49 Rui Maciel wrote:
>> > That makes no sense. Yes, it is very hard to maintain it, but there's
>> > no reason why moc would make it more difficult.
>> 
>> Don't you agree that the added work needed to develop and maintain a
>> specialized macro preprocessor in order to use a library ends up taking
>> more work than simply developing the application framework alone?
> 
> No.
> 
> You're making the woefully wrong assumption that the library code would be
> the same if moc didn't exist. That's a blatant error. 

I didn't assumed that, mainly because that assumption would be absurd. 


> Please add the need
> to write and maintain the glue code that moc provides, or equivalent
> technology.

If we look at what moc provides[1], it is summed up in two features: a base 
class "for objects that can take advantage of the meta-object system" and a 
macro which is used to provide "meta-object features, such as dynamic 
properties, signals, and slots".  Inheriting a base class is supported by 
programming languages such as C++ and a preprocessor isn't required to 
implement signals and slots[1], which is described as "the main reason for 
introducing" Qt's meta-object system.


> You're also assuming that maintaining moc is hard. That's also wrong.

Again, I've not assumed any of the things you pointed out.  Yet, I believe 
we can agree that, no matter how easy it might be, being forced to develop 
and maintain a preprocessor requires more work than not having to develop 
and maintain a preprocessor.  


>> It does what?  Your reply doesn't address any of the sentences you
>> quoted.
> 
> Yes, it does "force KDE to stick with Qt".
> 
> KDE stopping its use of Qt would mean rm -rf *

Major rewrites tend to assume the form of major rewrites.  For example, if 
Trolltech stopped developing Qt before releasing Qt4, what would the KDE 
project have decided to do?  


Rui Maciel

[1] http://libsigc.sourceforge.net/