From kde-core-devel  Sat Jan 06 10:01:28 2007
From: =?iso-8859-1?q?Andr=E9_W=F6bbeking?= <Woebbeking () kde ! org>
Date: Sat, 06 Jan 2007 10:01:28 +0000
To: kde-core-devel
Subject: Re: private slots
Message-Id: <200701061101.28706.Woebbeking () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116807769630985

On Saturday 06 January 2007 10:44, Ellis Whitehead wrote:
> On 1/4/07, Olivier Goffart <ogoffart@kde.org> wrote:

> > line 2460 of qobject.cpp
> > in QObject::connect
> >
> > QMetaMethod rmethod = rmeta->method(method_index);
> > if ( receiver != this  && rmethod.access() == Private)
> >         qWarning("cannot connect to a private slot");
> >
> > but wait...  QObject::connect is static ...  so there is no this
> > :-( (but i'm sure this can be worked around.)
>
> A problem with the "this" approach is that programmers will expect to
> be able to connect to the private slot of another object of the same
> class...
>
> One possibility might be to check the receiver's class.  However, for
> whatever it's worth, .NET doesn't prevent calling private methods via
> introspection either.  I'm not sure whether it's really desirable to
> prohibit it, anyway, 

Why do we use protected and private methods at all, lets make them all 
public ;-)

> at least not if an application programmer will 
> have to go to an extra effort to even figure out that there's a _k_*
> slot that could be called in the first place.

Maybe a bad habit but very often I use the source code instead of the 
docs so I would "find" the _k_* slot very fast.