[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: signals and slots vs. virtual_hook (was [PATCH] KFileDialog
From:       Rafael =?iso-8859-15?q?Fern=E1ndez_L=F3pez?= <ereslibre () kde ! org>
Date:       2008-07-15 21:28:22
Message-ID: 200807152328.25591.ereslibre () kde ! org
[Download RAW message or body]


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.

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]