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

[Rafael Fernández López]

Hi,

> 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...


Regards,
Rafael Fernández López.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080715/30f4f376/attachment.sig>