signals and slots vs. virtual_hook (was [PATCH] KFileDialog overwrite confirmation)
Rafael Fernández López
ereslibre at kde.org
Tue Jul 15 22:28:22 BST 2008
> 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
> #define KDE5ERROR
> or something like that.
> but i'm not sure it would ease porting
Hmm, don't know... In theory just grepping for KDE*4 could make the trick. I
am sure not everybody will agree defining "a macro?" which prints out a
warning right now that we are working on KDE4, but an error that prints out an
error on KDE5 is not very polite. ;)
> 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
No harm. When you already have X entries and you have _the virtual table_, one
entry more is no harm at all.
> 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.
Hmm, I don't see the problem... can you elaborate ?
> 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.
Yes, very probably...
Rafael Fernández López.
-------------- 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