On Wednesday, 21 de September de 2011 18:49:04 Stephen Kelly wrote: > >> Another solution (also by way of adding an indirection) is to add a > >> function that emits, which is protected. > >> > >> template <typename Klass, typename... Args> > >> void QObject::emitSignal(void (Klass:: *signal)(Args...), Args... args); > >> > >> Then you'd write: > >> emitSignal(&Me::textChanged, newText); > >> instead of: > >> emit textChanged(newText); > >> > >> The template magic to make that happen is already present. > >> > >> However, it would be completely source-incompatible with the existing > >> code, which is a big no-no. It would require making the signal functions > >> themselves not do anything -- only serve as identifiers. > > > > For source compatibility they could be implemented by moc to work as > > currently, no? > > Oh, they need to keep the current implementation so that SIGNAL and SLOT > based connections still work. Never mind me.
The old connection mechanism is almost guaranteed to work.
The problem is to update "emit" lines, which are calls to functions that cause
the signal to be emitted.
Also note that the solution above doesn't fix the following case:
otherObject->emitSignal(&Them::textChanged, newText);
Just as it doesn't protect today:
emit otherObject->textChanged(newText);
The big difference is that "emitSignal" would be protected in QObject, so any
class deriving from QObject would have access to it.
We've been looking at this for a year. If anyone has more interesting ideas,
they are more than welcome. But please try to write the proof of concept first.
Our conclusion is that if you want compile-time checking of the arguments, you
need to give up the protectedness of the emission.
--
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
