signals and slots vs. virtual_hook (was [PATCH] KFileDialog overwrite confirmation)
ogoffart at kde.org
Tue Jul 15 21:37:32 BST 2008
Le mardi 15 juillet 2008, Rafael Fernández López a écrit :
> Hi there,
> First of all, I don't want this thread to become an open war. I also
> wouldn't like this thread to become the typical endless thread from which
> we will get 0 advantage from it.
> From the original thread you can see the discussion was moving towards on
> how to preserve the binary compatibility. And what methods we have for
> that. We actually have some of them, but since our libraries are becoming
> bigger and bigger each day, I thought we could talk on how to stablish a
> canonical way of making them extendable without breaking binary
> Imagine we are writing a library, and we need a new method
> "myVirtualMethod" be added without breaking binary compatibility.
> I will revisit 3 techniques, but only 2 are really doable in all cases, so
> let's go on:
> - Over 1): sharing d pointers can be dangerous from my point of view. A
> subclass shouldn't have access to the very private members of a base class.
> Also, sharing d pointers is not always possible.
sharing d pointer is just _not_ possible between libraries when you want to
So we agree that 1) is a bad idea
> - Over 2): we do export on our libraries classes that aren't QObjects, so
> directly the signals/slots connections are not possible.
> - Over 2): we already have tons of signals/slots on our code in general.
> The code seems to mix with the rest, even if we add a comment "### KDE 5:
> make this virtual".
There is at this point exactly no differences.
We could maybe add a marco which would do nothing in kde4, but that we could
redefine in KDE5 to throw a compilation error or warning
or something like that.
but i'm not sure it would ease porting
Over 3): Adding a virtual function grow the virtual table. It might be
negletible. but this would be added to all of our virtual tables anyway. But
with QObject we already have that hook for free
Over 3): How with an enum do you handle conflicts between libraries? For
exemple if libkopete want to maintain BC and use some of the virtual hooks
and then we need to add another hook in kdelibs, we need to take it in
account, which might not be easy.
The current policy is using 2) for class than inherit from QObject, and 3) for
other classes that may need it. And i think it is a good policy.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel