signals and slots vs. virtual_hook (was [PATCH] KFileDialog overwrite confirmation)

Rafael Fernández López ereslibre at
Tue Jul 15 13:14:18 BST 2008


> 1) There's BaseClass, where virtual_hook is defined initially
> 2) There's MiddleClass: public BaseClass
> 3) There's DerivedClass: public MiddleClass
> 4) We decide that MiddleClass needs a new public, virtual function. We
> implement that by way of a non-virtual public and by overriding the
> virtual hook in MiddleClass and in DerivedClass.
> 5) Where did the enum get defined?
>   5.a) BaseClass, which means you must modify the most basic class in the
> hierarchy, which sometimes you can't or don't want to
>   5.b) MiddleClass, which is the "proper place"

Yes, I'd say 5.b)

> However, if you do modify MiddleClass, what happens when BaseClass needs a
> virtual? It has to be sure not to use the same enum value that was used
> in MiddleClass -- wherever that middle class ended up being.

That shouldn't be much trouble.

enum NewVirtualMethods {
     MyNewVirtual1 = 0,


enum NewVirtualMiddleClassMethods {
     MyNewVirtual4 = VirtualMethodCount

> Besides, my point is exactly that qt_metacall *is* the same as
> virtual_hook. There's no need to involve signals here. Technically all
> you needed to do was:
> void MiddleClass::publicFunction(bool b)
> {
>     void *args[] = { &b };
>     int id = metaObject()->indexOfMethod("privateFunction(bool)");
>     qt_metacall(QMetaObject::InvokeMetaMethod, id, args);
> }
> In other words, the enum gets replaced by the indexOfMethod call. That
> guarantees that you find the most derived implementation. That also
> guarantees that there will be no clash by adding more methods in the
> hierarchy.
> Finally, and this is the strongest argument of all: KDE 4's API was
> designed with this recommendation in mind. Let's not change it now.

Yes, I know, the only strong argument on the side of virtual_hook I  
guess that it is that we already have lots of signals/slots out there,  
and it is very probably that in the mess we just miss things to port.  
I mean, I have read code "// KDE2: rework this" on certain KCMs.

I don't want to change such a policy like this _RIGHT NOW_ (mainly  
because it is at double time, impossible and nosense), but just  
thinking on the future, and an easier maintenance in the future.

Making code both easy and safe to extend is a really great feature of  
any system.

Rafael Fernández López.

More information about the kde-core-devel mailing list