On Wed, 21 Sep 2011 23:43:34 +0200, Thiago Macieira <[email protected]> wrote:
> What is worse for you, that someone unintentionally emits a signal, or
> that
> you fail to connect because someone made a typo, or accidentally left the
> variable names in the SIGNAL or SLOT definition. Not to mention in
> refactoring
> this problem might creep in, because the code compiles but fails at
> runtime.
> Don't forget you have to match *exactly* the signature, of the exact same
> types, in the exact same typedef and namespace description.
I've been through the latter multiple times. I didn't care so far.
> You may say you're a very good developer and you check all connections
> (by testing the return value or by running with QT_FATAL_WARNINGS=1).
> Are you sure you tested all of the connection possibilities in your code?
> There is no chance that there was a connect() call that went untested?
> How about your co-workers, are they as good as you?
Ooh, I think I left a wrong impression on how I think of my own abilities
as a developer. I hardly ever check the return values of connect
statements (which is probably why I fell for the Q_ASSERT trap).
>> 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
>
> I beg to differ. I think the lack of compile-time checking that the
> connection can succeed is the one causing most issues.
Then we disagree.
> You know that we have a way of marking every line where we are emitting a
> signal, right? We created a macro for this, it's called "emit".
Yes. The emit keyword is used at developer discretion. It's not a
requirement for signal emission to be successful.
> If you need to muck around with the internals, you must have a good
> reason.
Exactly. Shouldn't the code somehow show you're going off-track?
emit someObject->someSignal()
doesn't cut it for me.
> Then you might as well have a little more performance.
This just feels like another incentive towards 'abuse'. You have the
performance just where you need performance. In the internals.
> Not to mention that you made a serious mistake above by placing
> "(int,int,int)": in invokeMethod, you do not list the signature. Imagine
> if
> this were production code! It wouldn't work and it might go undetected
> for years.
Yikes. Maybe that explains that when I use it, I have to test five times.
Also, I tend to notice that things don't work earlier than things that
work, but behave strange every now and then.
> Also a VERY BAD idea. Q_ASSERT expands to empty in release builds. So if
> you
> test in debug mode and everything works, when you compile in release
> mode
> things will suddenly stop working!
Right, that was me being stupid. I should really stop dry coding stuff in
e-mails... Don't Q_ASSERT then, but assert (and I do not necessarily mean
assert()).
> So, tell me, after making two very big mistakes in one email due to the
> current syntax, wouldn't you rather your compiler told you that you had
> made mistakes?
The latter of those wouldn't be caught by the compiler. The invokeMethod
example I expected to be wrong, didn't I?
I'm still not convinced that the trade-off is worth your while, but you
obviously think it is. There's downsides and upsides to both approaches.
Cheers,
Frans
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
