[Qt-interest] The argument for Qt

[Scott Aron Bloom]

Just to make everyones life a little easier... Im making a request..

Before this discussion continues about MOC of  all things...  READ
Thiago's blog http://www.macieira.org/blog/2011/09/the-future-of-moc/

Its an easy and quick read, and readily refutes the "Moc is just a
preprocessor" point of view... bringing up points I knew but wasn't
thinking of...  

That whole property thing was obvious.. but what I forgot, MOC does
signals while maintaining binary compatibility (its not a big deal to
me, so I forget it often)

Can we now move on, maybe to the press release that a new Windows movile
nokia phone was just announced?

Scott

-----Original Message-----
From: qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com
[mailto:qt-interest-bounces+scott.bloom=onshorecs.com at qt.nokia.com] On
Behalf Of Thiago Macieira
Sent: Thursday, October 20, 2011 3:01 PM
To: qt-interest at qt.nokia.com
Subject: Re: [Qt-interest] The argument for Qt

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