KDE/kdelibs/kdeui/jobs

David Faure faure at kde.org
Wed Apr 8 17:25:27 BST 2009


On Wednesday 08 April 2009, Andreas Pakulat wrote:
> On 08.04.09 14:08:26, Lubos Lunak wrote:
> > On Wednesday 08 of April 2009, Andreas Pakulat wrote:
> > > On 07.04.09 21:21:47, Raphael Kubo da Costa wrote:
> > > > 2009/4/7 Andreas Pakulat <apaku at gmx.de>:
> > > > > On 07.04.09 21:12:30, Raphael Kubo da Costa wrote:
> > > > >> SVN commit 950837 by rkcosta:
> > > > >>
> > > > >> Make killJob a private slot.
> > > > >
> > > > > Shouldn't it rather be Q_PRIVATE_SLOT(d,_k_killJob()) and then the
> > > > > _k_killJob method would be a member of the Private class?
> > > >
> > > > I don't know. Would it make any difference?
> > >
> > > Yes, because that allows to rename/remove the slot without breaking binary
> > > compatibility, while with the current private slot you can't ever change
> > > the slot in any way.
> > 
> >  How does changing a private: slot affect binary compatibility in any way?
> 
> Hmm, guess I need to be more explicit, of course I only meant the
> signature, not the actual implementation.

That's what Lubos meant too ;)
And he's right in theory, changing the signature of any private method is fine.
The only thing is, that a slot can be called anyway, by name, so we better
make it as hidden and "marked as internal" as possible (which is done by the _k_ prefix),
otherwise people might be tempted to do an invokeMethod on it by name.

I admit that I don't see the difference between Q_PRIVATE_SLOT and
"private slots:" for this; the only difference is whether you want the implementation
to be in d or q.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list