I've been following this discussion since the beginning, but only briefly participated on devnet. It took a while for me to get my exact thoughts about this lined up, and a lot has already been discussed, but here goes.
On Wed, 21 Sep 2011 19:20:06 +0200, Thiago Macieira <[email protected]> wrote: > Our conclusion is that if you want compile-time checking of the > arguments, you need to give up the protectedness of the emission. To be honest I never really understood why one would insist on compile-time checking of something that was obviously intended to be used and checked at run-time. However, I can't really make a proper argument against the new syntax though if this checking is actually a hard requirement for the future. I can only agree that as it looks now, the solution that gives the cleanest code and is probably most natural to use will be the one with the public signals. Bottom line for me, though, is that I don't agree with the trade-off made here: you're trading compiler checks on unintentionally messing about from unrelated pieces of code for compiler checks on possible connections. One of the two is more likely to produce weird results, and my gut says a solution with publicly accessible signals is the one. Get some bad signal names, code completion, and your average lazy developer (are there non-lazy devs?) and you're set. The simple fact is that public signals doesn't discourage you from writing bad code. Isn't API design about just that? Making writing good and predictable code easy and bad code harder? Consider: otherObject->someSignal(arg1, arg2, arg3); and the current QMetaObject::invokeMethod(otherObject, "someSignal(int,int,int)", arg1, arg2, arg3); The first looks like your average piece of code and can easily be overlooked, the second looks like messing around unless you know what you're doing. When reviewing or debugging, I'd rather have the latter piece of code, simply because it's suspiciously suspicious (and maybe even wrong, didn't check that). As far as I understand, the string based versions for run-time defined signals and slots are still required. Sticking to the old syntax will keep a common syntax for both use cases. If a connection is vitally important to the workings of the system I'd just use Q_ASSERT(connect(...)). Detection guaranteed. There's my couple of cents. Cheers, Frans _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
