private slots

[Ellis Whitehead]

On 1/4/07, Olivier Goffart <ogoffart at kde.org> wrote:
> Le jeudi 4 janvier 2007 18:51, Simon Hausmann a écrit:
> > On Thursday 04 January 2007 18:45, André Wöbbeking wrote:
> > > On Thursday 04 January 2007 17:45, Simon Hausmann wrote:
> > > > On Thursday 04 January 2007 17:24, André Wöbbeking wrote:
> > > > > Can you still connect to private slots from "outside"? If so you
> > > > > can call every private slot.
> > > >
> > > > Yes, that is correct.
> > >
> > > Why is that still possible? Couldn't it be disallowed in
> > > QObject::connect()? Of course this should be done for protected slots
> > > too.
> >
> > Sure could disallow it, but how do you detect when to allow it then? :)
>
> 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, 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.

Cheers,
Ellis