What would you think if you find somebody naming a function “publicDoSomething”? Or “voidDoSomething”? Or even “protectedVoidDoSomethingConst”?
It may be well what I think if these days I see somebody naming a function “slotDoSomething”. Although when I started with Qt programming you could see me giving similar names here and there. But this was just because I was following the great principle of Doing New Things By Example ™. And obviously some people had started before to apply some kind of partitial verbose hungarian notation to method names. And a funny thing about pattern based learning systems, like I and surely others are/were, is that they take correlating variations as hints to rules. And start to overdo: We see some methods that are slots being prefixed with “slot”, well, so we prefix them all. No idea, who started when and why, but now it’s there.
And I consider it to make the resulting code dirty. Being a slot is just a property of a method. Like “const”, the visibility, the return type or the types and number of parameters. All the latter properties is not referred to in the naming of the method, at least in the code I know. So why the being-a-slot property? I see no advantages, only disadvantages.
Methods that are given the property “slot” can be divided into two groups:
- methods with a semantic to others
- methods with a semantic to only the object itself
The first ones are functions which have a defined operational semantic, reflected in the method name, like “doFoo”. So other objects can call this method to achieve something. They are also set as slots because the operations done by the method make sense to be synchronized to certain events, by signals. Still the name is only based on the operational semantic. These functions are to be called by others (if only subclasses), so they are visible public or protected, e.g.:
class FooBar {
public Q_SLOTS:
void doFoo();
protected Q_SLOTS:
void doMoreFoo() const;
};
If one wants to synchronize an operation of the object to an event of another object, it writes:
connect( anotherObject, SIGNAL(bar()), object, SLOT(doFoo()) );
The latter ones differ in that they are methods whose only purpose is to catch dedicated signals. Signals with a given semantic. As reflected in the signal name, like “Done”. No other object will ever call these method, perhaps even not the object itself. It is only connected to the signal and called on it’s emission. So the semantic of the method is react-on-signal-x. In other languages like Javascript or Delphi those methods have a naming pattern: “onSomething” for the signal “something”. Makes much sense to me. Why should Qt programming be done differently?
Because these method can be only sensefully used by the class itself they are visible private, e.g.:
class FooBar {
private Q_SLOTS:
void onBar() const;
};
So connecting is done within the object by:
connect( anotherObject, SIGNAL(bar()), SLOT(onBar()) );
How beautiful is this code?
Think about it. A slot is just a property. Name your functions after the semantic, if is available to others, or the signal. Omit the property.
Well, or just disagree 😛
Hm, not yet convinced? Than take your final push:
“on” is two letters less to type. And two characters less to compare on function lookup, so results in faster linking. A little, at least. 😉 And without “slot” it is even four letters less.
Now you are convinced, right? Then go and improve your KDE code. Now! 🙂
Updated:
From your comments I guess I was not too clear, hope the added text now helps to understand better what I mean. Some things should simply get some more days to be written, sigh.
Attracted by virtual constructs 