kwallet binary compatibility

[Michael Pyne]

On Thursday 21 August 2008, Michael Leupold wrote:
> Hi,
>
> I have a question regarding kdelibs binary compatibility. I'm currently
> working on some parts of the kwallet backend (KDE/kdelibs/kwallet). These
> classes are meant to be internal but still they have KDE_EXPORT declared.
>
> Does that mean that I have to make a kwalletbackend2 and declare the old
> library deprecated? (By the way, no client code will have to be changed but
> the one in kwalletd - unless someone decided to use libkwalletbackend
> directly).

I would argue that unless it was made clear in the API that they were meant to 
be internal that the KDE_EXPORT implies they are public.

For instance if the class name doesn't end in Private, use prefix underscores 
or _k_, or is not marked internal in the API documentation then the KDE_EXPORT 
would allow people to surmise that the class was public API.

In addition if applications linking against kwallet linked against that class 
(it's exported after all) then maintaining binary compatibility would mean 
that you can't break that class even if we do declare it as internal later.

These are just my thoughts but I would run nm on like kwalletmanager or 
something and see if your classes are listed in there.

Regards,
 - Michael Pyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080821/b685efac/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080821/b685efac/attachment.sig>