QMetaObjectBuilder in QtDeclarative and QtSystems

[Lorn Potter]

Hi,

Currently, there are 3 instances of QMetaObjectBuilder, in QtDeclarative, QtSystems
(serviceframework) and QtSystems (publish and subscribe). There are only trivial changes between
these existing versions of QMetaObjectBuilder private class.



Any objections if I add a QMetaObjectBuilder to qtbase in qtcorelib, so to remove code duplication,
(and I can use it as well)?
I will use the code from QtDeclarative module.


The respective owners of those modules/code should then probably remove their versions and convert
their code to using the one in QtBase.


comments?

[Thiago Macieira]

Post by Lorn Potter
Hi,
Currently, there are 3 instances of QMetaObjectBuilder, in QtDeclarative,
QtSystems (serviceframework) and QtSystems (publish and subscribe). There
are only trivial changes between these existing versions of
QMetaObjectBuilder private class.

Don't forget QDBusMetaObjectWriter and the original meta object creator in
ActiveQt.

Post by Lorn Potter
Any objections if I add a QMetaObjectBuilder to qtbase in qtcorelib, so to
remove code duplication, (and I can use it as well)?
I will use the code from QtDeclarative module.
The respective owners of those modules/code should then probably remove
their versions and convert their code to using the one in QtBase.
comments?

Good idea.

I just hope that a generic solution with the new code isn't performing much
worse than the specific solutions the older codebases had.

[Olivier Goffart]

Post by Lorn Potter
Hi,
Currently, there are 3 instances of QMetaObjectBuilder, in QtDeclarative,
QtSystems (serviceframework) and QtSystems (publish and subscribe). There
are only trivial changes between these existing versions of
QMetaObjectBuilder private class.
Any objections if I add a QMetaObjectBuilder to qtbase in qtcorelib, so to
remove code duplication, (and I can use it as well)?
I will use the code from QtDeclarative module.
The respective owners of those modules/code should then probably remove
their versions and convert their code to using the one in QtBase.

The reason why i don't like those is that it is really exposing a lot of the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that we
want. That is, something like
QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.

Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

[l***@nokia.com]

Post by Olivier Goffart

Post by Lorn Potter
Hi,
Currently, there are 3 instances of QMetaObjectBuilder, in
QtDeclarative,
QtSystems (serviceframework) and QtSystems (publish and subscribe). There
are only trivial changes between these existing versions of
QMetaObjectBuilder private class.
Any objections if I add a QMetaObjectBuilder to qtbase in qtcorelib, so to
remove code duplication, (and I can use it as well)?
I will use the code from QtDeclarative module.
The respective owners of those modules/code should then probably remove
their versions and convert their code to using the one in QtBase.

The reason why i don't like those is that it is really exposing a lot of the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that we
want. That is, something like
QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.
Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

I would also prefer to keep it private to start with :)

But yes, let's reduce the code duplication and rather have one well tested
version.

Cheers,
Lars

Post by Olivier Goffart
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[a***@nokia.com]

-----Original Message-----
Behalf Of Knoll Lars (Nokia-MP-Qt/Oslo)

Post by Olivier Goffart
The reason why i don't like those is that it is really exposing a lot of the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that we
want. That is, something like
QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.
Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

I would also prefer to keep it private to start with :)
But yes, let's reduce the code duplication and rather have one well tested
version.

I believe Lorn just forgot to mention this tiny little detail.... Yes, it's only going to be a private export.

--
Alex

[Gábor Lehel]

-----Original Message-----
Behalf Of Knoll Lars (Nokia-MP-Qt/Oslo)

Post by Olivier Goffart
The reason why i don't like those is that it is really exposing a lot of the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that we
want. That is, something like
QObject::addDynamicSignal(...)  QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.
Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

I would also prefer to keep it private to start with :)
But yes, let's reduce the code duplication and rather have one well tested
version.

I believe Lorn just forgot to mention this  tiny little detail.... Yes, it's only going to be a private export.

If this is what I think it is and what it looks like it is, I wouldn't
be surprised if it were reimplemented a few times again in various
language bindings. (I would be a lot more surprised if it weren't).
Having it publicly available might be useful.

--
Alex
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[l***@nokia.com]

Post by Gábor Lehel

Post by a***@nokia.com

-----Original Message-----
Behalf Of Knoll Lars (Nokia-MP-Qt/Oslo)

Post by Olivier Goffart
The reason why i don't like those is that it is really exposing a lot
of
the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that we
want. That is, something like
QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.
Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

I would also prefer to keep it private to start with :)
But yes, let's reduce the code duplication and rather have one well tested
version.

I believe Lorn just forgot to mention this tiny little detail.... Yes,
it's only going to be a private export.

If this is what I think it is and what it looks like it is, I wouldn't
be surprised if it were reimplemented a few times again in various
language bindings. (I would be a lot more surprised if it weren't).
Having it publicly available might be useful.

Long term we should consider that, but it's probably better to keep it
private in the first version.

Cheers,
Lars

[Hugo Parente Lima]

Post by Gábor Lehel

Post by a***@nokia.com

-----Original Message-----
Behalf Of Knoll Lars (Nokia-MP-Qt/Oslo)

Post by Olivier Goffart
The reason why i don't like those is that it is really exposing a lot of the
internals, and that using them is complicated.
A better alternative would be to have public API to do the things that
we want. That is, something like
QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a
dynamicslotevent), or whatever that api is used for.
Now, if these classes stay private anyway, i don't object. (because reducing
code duplication is a good thing)

I would also prefer to keep it private to start with :)
But yes, let's reduce the code duplication and rather have one well
tested version.

I believe Lorn just forgot to mention this tiny little detail.... Yes,
it's only going to be a private export.

If this is what I think it is and what it looks like it is, I wouldn't
be surprised if it were reimplemented a few times again in various
language bindings. (I would be a lot more surprised if it weren't).
Having it publicly available might be useful.

Yes, e.g. PySide has it's own dynamic metaobject implementation, a public API
to create/destroy dynamic signals/slots would be great for all language
bindings.