Signals: Is this the expected behaviour of connect() ?

[Thiago Macieira]

On Monday 25 February 2008 12:08:00 David Faure wrote:
> On Monday 25 February 2008, Thiago Macieira wrote:
> > Eduardo Robles Elvira wrote:
> > >And indeed, it seems that signals were designed somehow  to be only
> > > triggered by it's owner (and friends & parents).  You cannot do emit
> > > new
> > >A()->signalA(); inside B. It doesn't even compile because the signal
> > >is "protected". But then, as the given code shows, connecting signalB()
> > > to signalA() and triggering signalA(), works fine - so maybe this is a
> > > bug?
> >
> > No.
> >
> > Signal to signal connection is allowed and part of the design.
>
> Well, yes, but usually that's for relaying signals, not for forcing another
> unrelated class to emit a signal.
>
> If this kind of use case was part of the design, then "signals:" might as
> well be defined "public:" instead of "protected:".
>
> I think this is just a side effect of the fact that signal/slots
> connections bypass private/protected/public protection, but I certainly
> wouldn't call this kind of hack "part of the design".

I'd say that, if you want to force another class to emit a signal, you 
wouldn't use signal-to-signal connecting. Why add overhead when all you need 
is an innocuous static_cast?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080225/85897c70/attachment.sig>