----- Original Message ----- > From: Thiago Macieira <[email protected]> > To: [email protected] > Cc: > Sent: Thursday, September 22, 2011 11:33 AM > Subject: Re: [Qt5-feedback] QObject: new signals-slots syntax > > On Thursday, 22 de September de 2011 14:06:05 Olivier Goffart wrote: >> I almost managed to get the signal private: >> >> >> class Foo { >> public: >> class Signal { //This would be in the Q_OBJECT macro. >> ~Signal() {}; // private destructor > > Q_DISABLE_COPY(Signal) > >> friend class Foo; //<- problem: Q_OBJECT macto does not know > "Foo" >> }; >> >> Signal bar(); //New way of declaring signals, moc detect the return > type >> }; >> >> int main() >> { >> Foo::Signal (Foo::*sig)() = &Foo::bar; // works >> Foo f; f.bar(); // error, ~Signal is private >> return 0; >> } >> >> >> But this mean signals are now private instead of protected (which i think > is >> maybe a good thing) and that Q_OBJECT should be changed to know which >> class it it in so it can put the friend. > > That requires changing every single header defining a QObject-derived class. > It > might be automatable, but I'm not sure it will catch every case. > > Making signals private is IMHO much worse than making them public. Take for > example signal QIODevice::readyRead(): it's emitted from almost all classes > deriving from QIODevice (notable exception is QFile). In order to fix that > case, we'd need to add a signal-emitting function. But in any case, this is > way source-incompatible and I doubt it is automatable at all. >
This is why I'd like to see SIGNALS be supported at all three levels - public, protected, and private. That would allow you to have some signals - like QIODevice::readyRead() that are fully public - and other signals - like an internal read that buffers the data - that are protected; and you could have other signals that are private for whatever you needed internally. Granted, of that, the private is the least likely to be used, but protected signals could be very beneficial. I think when I brought it up last, it was pointed out that class functions could do that without signals, but that would leave you without being able to call other objects you are utilizing via signal/slots. This would also be source compatible since it would not be required that you have protected signals. The easy way to do it would be to allow Q_SIGNALS to continue in the same public signals behavior and introduce a new one (Q_PROTECTED_SIGNALS) to add the new behavior. Ideally it would be good to use the Q_SIGNALS macro like one uses the Q_SLOTS macro, but that would be source incompatible - this could at least provide that functionality until the next round where binary or source compatibility is not required. $0.02 Ben _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
