[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: private slots
From:       André_Wöbbeking <Woebbeking () kde ! org>
Date:       2007-01-06 10:01:28
Message-ID: 200701061101.28706.Woebbeking () kde ! org
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]