--nextPart3723246.Io4WjM1lXt
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le mardi 15 juillet 2008, Rafael Fern=C3=A1ndez L=C3=B3pez a =C3=A9crit=C2=
=A0:
> 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 clas=
s.
> Also, sharing d pointers is not always possible.

sharing d pointer is just _not_ possible between libraries when you want to=
=20
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.=20

We could maybe add a marco which would do nothing in kde4, but that we coul=
d=20
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 =20




Over 3):  Adding a virtual function grow the virtual table. It might be=20
negletible. but this would be added to all of our virtual tables anyway. Bu=
t=20
with QObject we already have that hook for free

Over 3): How with an enum do you handle conflicts between libraries?  For=20
exemple if libkopete want to maintain BC and use some of the virtual hooks=
=20
and then we need to add another hook in kdelibs, we need to take it in=20
account, which might not be easy.




The current policy is using 2) for class than inherit from QObject, and 3) =
for=20
other classes that may need it.  And i think it is a good policy.
=20

--nextPart3723246.Io4WjM1lXt
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBIfQqOz58lY8jWrL0RAnIFAJ9VewXtBhLCI+Gi85oZBKozMGHVkgCfdk+s
ImdHbPK5QQnINxeAERjrGxI=
=0Wqq
-----END PGP SIGNATURE-----

--nextPart3723246.Io4WjM1lXt--