[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

Allan Sandfeld Jensen kde at carewolf.com
Sat Feb 29 10:40:48 CET 2020


On Friday, 28 February 2020 16:28:34 CET Matthew Woehlke wrote:
> On 27/02/2020 17.03, Allan Sandfeld Jensen wrote:
> > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
> >> On 26/02/2020 07.42, Tor Arne Vestbø wrote:
> >>> As others have argued, a signal is not special, in the sense that any
> >>> function can do anything, including emitting signals, so annotating it
> >>> doesn’t seem critical, as we apparently are fine without in all other
> >>> cases.
> >> 
> >> Taking a step back... I think some of the reason for the current
> >> situation has to do with API design. Which of these is easier to
> >> understand?>> 
> >>   if (map.empty())
> >>   
> >>     emptied();
> >> 
> >> - vs. -
> >> 
> >>   if (map.isEmpty())
> >>   
> >>     emit emptied();
> >> 
> >> One reads like plain English. The other is missing words in a way that
> >> can confuse readers.
> > 
> > That is how I see it too. It essentially violates Qt code guidelines. If
> > it
> > was a normal method we would name it "emitEmptied()", so far we have just
> > lived with "emit emptied()" instead.
> 
> I still have to disagree. *The signal* is "emptied". It is *not*
> "emitEmptied".
> 
> If we had to do it over again, it might make sense to follow Python and
> make signals *objects* instead of *methods*. Then the code would look like:
> 
>   this->emptied.emit(...);
> 
> But I *equally do not* want to write:
> 
>   connect(foo, &Foo::emitEmptied, ...);

I agree with the latter. We would need another syntax for connecting if the 
method names all began with emit. The old SIGNAL() macro could easily be 
adapted, but the modern syntax would be a problem.

'Allan





More information about the Development mailing list