On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote: > On Fri, 21 Feb 2020 at 22:11, André Pönitz <apoen...@t-online.de> wrote: > > > > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote: > > > > I, for one, definitely want to see whether I am emitting a signal or > > > > not. > > > > > > Right; the claims that you can ignore signal emits when looking at a > > > piece of code or expect that they > > > don't affect the current scope are exactly backwards. > > > > Christian is right and your conclusion is wrong. > > My conclusion is fine. Your unsubstantiated claims don't make it wrong. > > > See the already mentioned example of debugging in code that follows > > the convention of using signals only for inside-out communication: > > Buy a debugger that can skip code that you didn't write.
The point was that in a such a situation I, as user, would not even try to step in when the call is marked with 'emit'. This 'emit' in a line *is* valuable markup, that saves me time. That's unrelated to what the debugger would or could do if I did step in, I just don't need to follow that path. [And apart from that: There's no need to *buy* such debugger, e.g. gdb's 'skip' actually works] > > Emitting the signal may cause all kind of activity on the outside, > > but in first approximation one can assume it doesn't change state in > > the current object. So when drilling down in this situation > > "ignoring" emit is indeed natural. > > Seems quite unnatural to me, considering that signal emissions > reasonably often tend to result in further calls being made to the object. I stated as pre-condition that this is about "code that follows the convention of using signals only for inside-out communication". > > This sounds a bit like the committee shot down the proposal to > > not use 'emit' without even bothering to think about reasons why > > there are users of this "nonsense", let alone tried to ask them. > > The committee shot down the proposal because > 1) there are work-arounds to the problem, and we already use those > work-arounds for similar > issues with boost::signal > 2) trying to avoid clashes with lowercase non-function-like macros is > rather difficult > 3) the scope of the problem is narrow > 4) no existing code is broken Is that documented, perhaps with a bit more detail, somewhere? Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
