[Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties

[Welbourne Edward]

Mitch asked:
>> Is this worth mentioning in the documentation?

Andre' P replied:
> I think it would make sense to list the features that are affected so
> that users can decide whether they actually need one of them, or not,
> instead of having this unspecific (and untrue) "strange things may
> happen".

The nearest I can get to thinking of a good reason to leave it
unspecific is that it leaves open the possibility that later versions of
Qt shall exhibit different strangeness due to a change in Q_OBJECT.
This is the usual rationale, for example in a standard, for saying that
certain usages may lead to "undefined" behaviour.  All the same, the
phrasing "strange things may happen" is a red flag - too vague to be
useful, so it makes Q_OBJECT sound like magic.  Prudent programmers
mistrust magic.

In the present case, I do think it is worth giving at least some idea of
what the problem with omitting Q_OBJECT is.  That can be phrased in
"undefined behaviour" terms to leave open scope for future changes, as
long as it gives the user enough information to make an informed
decision.  After all, a template class that inherits from a QObject
class *can't* (at present) use Q_OBJECT, because moc can't cope with
templates, so leaving out Q_OBJECT has to be an option.  That means the
client code's author needs to understand the pros and cons of that
option.  So we should at least outline which aspects of such inheritance
are likely to violate the principle of least surprise - which of the
promises that we make for a QObject-based class depend (or might, in a
future release, depend) on it using Q_OBJECT ?

	Eddy.