[Interest] Are slots even needed these days?

[André Somers]

Op 17/03/2016 om 00:46 schreef Bob Hood:
> On 3/16/2016 5:02 PM, Scott Aron Bloom wrote:
>> I find them both pretty bad L…  I have spent too much time, looking 
>> at other people’s code trying to figure out “why” it wont connect, 
>> only to realize someone had snuck in a “private:” second so moc 
>> didn’t generate the slot information.
>>
>> I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”
>>
>>
>> It really lets the methods stand out as slots and signals.. It also 
>> means, don’t think “sender()” can ever valid if you are not in a 
>> “slotXYZ” function.
>>
>>
>
> I actually prefix my slot method names with "slot_" and signals with 
> "signal_" so they are also easily identifiable in the C++ module as 
> I'm looking through the code.  More self-documentation.

And I happen to think that these naming 'conventions' are pure nonsense. 
I really don't care much _how_ a method is called. What's the difference 
between having a method called due to a signal emit and having a method 
called directly? None. I want my methods to be called after what they 
_do_, and not how they are called. What if I I find I have a need to 
call the "slot_" method directly from some other code as well? Should I 
be allowed? Of course I should be! Be the name slot_* suggests issues 
there that don't exist, especially if you don't use sender() any more 
(which has been discouraged for many years already anyway).

And as for people being used to seeing blocks of methods behind a 
'public slots:' access specifyer: sure, but it doesn't add much 
information. It only serves to create some kind of artificial grouping 
of your methods in your declaration that is probably not even all that 
sensible. For instance, if I have a class with many properties on it, I 
think it makes sense to keep the methods related to each property 
together, so I have a quick overview over what methods are available for 
what property. You'd see me writing this:

Foo foo() const;
void setFoo(Foo foo);
Q_SIGNAL fooChanged(Foo foo);

Bar bar() const;
void setBar(Bar bar);
Q_SIGNAL barChanged(Bar bar);

I find that much more readable than having to look in some signals 
section to find if there is a notification signal, and then in some 
slots section to see if the setter is perhaps declared as a slot or not.

For me, Q_SLOT or slots: has little value any more, other than making 
the methods callable in dynamic contexts like QML.

André

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160317/8fa2fb8b/attachment.html>