[Qt-interest] The argument for Qt

[Thiago Macieira]

On Thursday, 20 de October de 2011 21:57:08 Rui Maciel wrote:
> Thiago Macieira wrote:
> > 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.

I'm sorry, but you REALLY do not understand moc. I recommend you read my blog 
called "The future of moc" so you understand why it's there and why we need 
it.

It has nothing to do with the base class (that's all C++ as you pointed out). 
Signals and slots are just a part of it, but EVEN if we use a C++ method of 
connecting, which we will in Qt 5, we will still need moc for signals and 
slots. Not to mention everything else.

Go read the blog.

> > 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.

Yes and no.

	effort({moc}) > effort(empty_set)

	effort({moc, Qt libraries }) < effort({Qt libraries, moc replacement})

And this is even completely ignoring the fact that *removing* moc would take 
more effort than it takes to maintain moc for 5 years.

You're off the mark here because you assume that it's possible to remove moc. 
Let me be very clear: it's not possible to do what we do without moc.

> 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?

Continue with Qt 3 and eventually make a Qt 4 of their own.

Especially since back then, if Trolltech had stopped releasing Qt, the KDE 
e.V. would have received the Qt codebase under the BSD license and would be 
the sole custodian of it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20111021/f249f76f/attachment.bin