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