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é
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
