External Acces to Private Slot

[squidge]

Maybe you were confused by my response, as it basically states exactly the same as what you just replied with. Eg. that obj->func() will not work from outside the class but obj->InvokeMethod will.

To have your slots truly private, create them in another private class, and contain a pointer to this class in the private part of your public class. So if you need to access your private slots you can do d->slot() whilst people outside your class can not, as 'd' would be private.

This also means your class is more flexible - you can either have data for each instance of your class, or you can share data between instances of your class (like the Qt object classes).

[SixDegrees]

Slots, by their nature, are public, period. Private slots make no sense; private members are not accessible outside the class they belong to, so signals and slots make no sense, since a direct function call will do just as well in such instances. Slots are inherently public; they are meant explicitly for inter-class communication.

The whole pedantic discussion above would make more sense if protected slots were the topic. For private slots, it's just silly. And the protected case is actually more interesting; here, in order to preserve the traditional C++ meaning of "protected", the metadata system would have to keep track of object inheritance to ensure that only related classes could signal one another - which, again, is somewhat silly since the whole point is inter-object communication, but here it's somewhat less silly than it is when the topic is private slots. In the end, however, one would have to reproduce a signficant chunk of the C++ compiler in order to pull this sort of thing off.

And for what purpose? The goto statement is also considered "bad", but lots of people still use it, and even modern languages like Java support it despite being able to do perfectly well without it through the use of other, "better" constructs. Varying degrees of access protection are useful, but insisting on strict adherence to this paradigm in a signalling system is pointless. Anyone concerned about this is, presumably, a programmer. By implication, that means you should be aware of the potential pitfalls, and should simply avoid them.

[stefanadelbert]

Maybe you were confused by my response, as it basically states exactly the same as what you just replied with. Eg. that obj->func() will not work from outside the class but obj->InvokeMethod will.

To have your slots truly private, create them in another private class, and contain a pointer to this class in the private part of your public class. So if you need to access your private slots you can do d->slot() whilst people outside your class can not, as 'd' would be private.

This also means your class is more flexible - you can either have data for each instance of your class, or you can share data between instances of your class (like the Qt object classes).

Nice suggestion. Thanks.

I think that Qt should prevent connecting to private slots outside their classes.

This is basically what I'm saying. I don't believe that it should be possible for a private slot to be accessible outside that defining class.

Slots, by their nature, are public, period. Private slots make no sense; private members are not accessible outside the class they belong to, so signals and slots make no sense, since a direct function call will do just as well in such instances. Slots are inherently public; they are meant explicitly for inter-class communication.

The whole pedantic discussion above would make more sense if protected slots were the topic. For private slots, it's just silly. And the protected case is actually more interesting; here, in order to preserve the traditional C++ meaning of "protected", the metadata system would have to keep track of object inheritance to ensure that only related classes could signal one another - which, again, is somewhat silly since the whole point is inter-object communication, but here it's somewhat less silly than it is when the topic is private slots. In the end, however, one would have to reproduce a signficant chunk of the C++ compiler in order to pull this sort of thing off.

And for what purpose? The goto statement is also considered "bad", but lots of people still use it, and even modern languages like Java support it despite being able to do perfectly well without it through the use of other, "better" constructs. Varying degrees of access protection are useful, but insisting on strict adherence to this paradigm in a signalling system is pointless. Anyone concerned about this is, presumably, a programmer. By implication, that means you should be aware of the potential pitfalls, and should simply avoid them.

Thanks for your (fueled) response and your good points. Let's not get started on the inheritance of signals and slots though. It's clearly something that the Qt Keepers are aware of and it might be fixed up down the line.

I take your point about Qt signals and slots being an inter-class communication mechanism, but it is also very useful in other situations. For example,

Class A has a QTimer. It wants to do something private (modify some or other private member) when the timer times out. It connects signal QTimer::timeout() to its (private) slot MyVeryPrivateSlot(). But now that private slot can be connected to and triggered by anyone outside the class. Sure class A could call private function MyVeryPrivateFunction(), but how else could class A respond to QTimer::timeout() other than with a slot?

It was not my intention to enter into a ridiculously pedantic debate on the intricacies of Qt's signalling framework. I'm a fan, else I wouldn't be here. Just wanted to get some opinions on the topic and find out if there were any creative solutions.

[wysota]

There is a nice button on this forum under every post called "Multi-Quote This Message". Please use it next time instead of posting multiple posts.

As for the discussion: remember that access protection is done purely during compilation based on a very simple rule, there is no actual check made (run-time) whether one can call a particular method or not hence enforcing such check during run-time for Qt slots would only create overhead without any practical benefits. Many languages (like Python) have simply ignored access protection and treat all methods and fields as public. Working around protection in C++ requires 4-5 lines of code so if someone wants to have access to a private or protected member of some class, there is practically no way of stopping him. On pure academic level I can understand that Qt should support access protection to its signals and slots but as an engineer I say there is no practical argument to support this claim.

but how else could class A respond to QTimer::timeout() other than with a slot?

Through events.