[Development] From whence cometh Q_NAMESPACE?

[Matthew Woehlke]

On 11/06/2019 13.58, Giuseppe D'Angelo via Development wrote:
> On 11/06/2019 19:24, Matthew Woehlke wrote:
>> So, my questions are:
>>
>> 1. Is it really Qt's intent that using Q_NAMESPACE, etc. requires
>> including <QObject>?
>>
>> 2. If not, is it worth tweaking the documentation to make it clearer
>> that <QMetaObject> is sufficient?
>>
>> (I don't see why we would need to "specify that macro for multiple
>> targets"... just "move" it to QMetaObject. It should be clear that
>> <QObject> includes <QMetaObject>.)
> 
> I wouldn't rely on that transitive inclusion.

Considering that QObject uses sub-types of QMetaObject, I think it's
pretty safe...

> Anyhow, we have two problems at hand:
> 
> * one is a documentation one: how do we make these macros discoverable
> without spreading in N documentation pages?

I'm not convinced this is a problem, given the ability to add links.
(Personally, I *never* would have guessed to look for Q_NAMESPACE in
qobject.html, so I guess we couldn't do worse than now.)

> How do we specify what's the right include to get a macro (when it's
> a transitive include like this one)?

That's a much more interesting question. Right now, I'm not sure we
"specify" this at all. Kyle is implicitly going by which class's
documentation includes the macro (which isn't unreasonable), but that's
not very explicit.

> * another one is which one is the "right" include for pulling in the
> meta object macros. It could even be an include different from QObject
> and QMetaObject...

In general, I agree. (In practice, I would argue that right now
<QMetaObject> *is* the correct answer for those moc-related macros that
don't explicitly depend on QObject. For Q_OBJECT itself, of course, and
the signal/slot macros, I would argue for <QObject>, because good luck
having a Q_OBJECT that doesn't ultimately derive from QObject.)

-- 
Matthew