private slots

André Wöbbeking Woebbeking at kde.org
Sat Jan 6 10:01:28 GMT 2007


On Saturday 06 January 2007 10:44, Ellis Whitehead wrote:
> On 1/4/07, Olivier Goffart <ogoffart at 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.




More information about the kde-core-devel mailing list