On 16/06/15 23:19, "Stephen Kelly" <steve...@gmail.com> wrote:
>Stephen Kelly wrote:
>
>>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>>> please don't take that as me trying to shut the discussion down. :)
>>
>> Cool. Let's wait and see.
>
>This thread has gone way off-topic now, but we gathered a week of
>opinions
>and reasons, and I think it's time to put the thread to rest.
>
>Lars, what's your take on these two questions:
>
>1) What should be done for new modules with Qt 5.6+ ?
>
>2) What should be done with Qt3D?
This is mainly about how we use namespaces in Qt. We went through that
discussion during the times we moved from Qt 4 to Qt 5, and I was trying
to dog out the issues we had at that time.
During the time we worked on Qt 5, we actually discussed whether we should
move all of Qt into namespaces. It failed for several reasons. Some of
them are also valid for new code:
* (doesn’t really apply for new code) We couldn’t make things work in a
source compatible way. Moving from QObject to Qt::Object (or even
Qt::QObject) was not something you could do in a transparent way. We
thought about using a 'typedef Qt::Object QObject’ for compatibility. But
it would break things such as forward declarations and typedefs.
* connect statements are hard with namespaces. Old style connects could
easily break if you forgot to fully qualify a parameter. New style
connects might end up with rather ugly looking syntax.
* metatype registration is problematic with namespaced types, as the macro
extracts the name of the type through the preprocessor. People can very
easily end up registering the type multiple times with different
(qualified vs non qualified) names.
* One of our coding guidelines is that you write code once, but read it
many times. Code written should be as self explaining as possible. Having
generic class names inside an implicit namespace makes this difficult, as
information is not fully local anymore (you have to know that there’s a
using directive at the beginning of the file to find the proper qualified
class name). Generic and duplicated names from different namespaces can
easily lead to confusion when reading code. (btw, this is also an argument
against over-using auto)
* class name prefixing is a widely used and understood scheme by our
users. Do we really want an inconsistency now in one place? I don’t think
we have enough arguments to actually go down that route.
So what do we do with Qt 3D? For 5.5, we’re too late to do any changes.
But we’re talking about a Tech Preview here, so we can use it to collect
some feedback on the namespace usage in there. We will however need to
decide rather quickly whether we want to keep it or revert to regular Qt
style class name prefixing for 5.6. I’m currently leaning towards the
latter.
At the same time, I think we should start experimenting with namespaces
for Qt types. A way to do that that doesn’t disrupt current Qt development
is by adding headers that put the types into namespaces:
--
#include <QtCoreNamespace>
QtCoreNamespace:
class QObject;
namespace QtCore { // or should this simply be Qt?
using ::QObject as Object;
// or
class Object : public QObject {
using QObject::QObject;
}
}
--
Not sure this would work perfectly, but it might be worth a try :)
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
