[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:       Olivier Goffart <ogoffart () kde ! org>
Date:       2008-07-15 20:37:32
Message-ID: 200807152237.39562.ogoffart () kde ! org
[Download RAW message or body]


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
> compatibility.
>
> 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 
maintain BC.
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.

true.

> - 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
#define KDE5ERROR
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.
 

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

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