DRAFT document on coding conventions in kde libraries

[Friedrich W. H. Kossebau]

Am Montag, 6. März 2006 01:10, schrieb David Faure:
> On Sunday 05 March 2006 22:53, Friedrich W. H. Kossebau wrote:
> > So I ask what makes a slot method special at all, except being
> > additionally available for signal/slot connections to some events. Where
> > would tagging a method "slotMethod()" make the code more readable?
>
> You know when reading the method, that it will be called as a result of a
> signal emission, not (or rarely) as a direct method call.

Reading in the implementation source file, I guess? 
In the header and in the only other, by your usage disclaimer, appearance in 
"(dis-)connect()" commands it should be clear it's a slot, not?

As "slots" is defined away IIRC(?) why not put something like "slot" next to 
the method in the implementation as well? Would that do it for those who need 
it? If it could be done at all?

void QObjectSubClass::doSomething() slot {
}

> > And doesn't it even make
> > the code more unreadable in places where the signal/slot tricks are not
> > used but the method being called just normally?
>
> If it is called normally, then I wouldn't call it slotFoo()

Looks like a solution to the naming problem, then :)

Still I am curious. I did not code too much with Qt but I cannot remember to 
have written functions solely to be connected to signals. What design pattern 
is there hidden? (I only remember to have read somewhere that signal/slot is 
a dirty technique for less structured programming?)

> > Unless there is I would even ask to, ahem, forbid the "slotX" naming
> > convention... :)
>
> Veto! ;)

Let's hear :)

> > See, it seems not to be used in Qt itself, either!
>
> I agree that it's not widely used in Qt, but still:
> ./network/qhttp.cpp:85:    // private slots
> ./network/qhttp.cpp:87:    void slotReadyRead();
> ./network/qhttp.cpp:88:    void slotConnected();
> ./network/qhttp.cpp:89:    void slotError(QAbstractSocket::SocketError);
> ./network/qhttp.cpp:90:    void slotClosed();
> ./network/qhttp.cpp:91:    void slotBytesWritten(qint64 numBytes);
> ./network/qhttp.cpp:92:    void slotDoFinished();
>
> See, connected() would look like a method that returns a boolean telling
> the caller whether we are connected. On the other hand slotConnected()
> tells me right away that this is the slot connected (no pun intended!) to
> the connected signal. Same thing with closed() vs slotClosed().

Hm, this ambigousity could be solved by naming conventions resulting in 
isConnected() and onConnected() :) Or not missing the "//private slots" right 
above.

Oh, did I get onX from Objectpascal or Javascript? Now I remember that Delphi 
forced one to have many "OnX"... Hm. So perhaps for-signal-only methods 
really have some usage patterns? But if my patterns are different and I can 
call such methods directly without need for signal/slot that code will really 
look ugly. 

So my vote still: no slotX, no onX, from what I wrote above I think it's not 
really needed and hurts those who do not need to use signal/slots.

Could perhaps someone from Trolltech enlighten us why they choose only to use 
slotX with private slots? After all we do almost adore the rest of their api 
style so they could have a good reason here as well :P

That was about all my money I could throw in, left to you wiser coders :)

Regards
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060306/6c0c3d3b/attachment.sig>