kwallet binary compatibility

[Allen Winter]

On Thursday 21 August 2008 20:50:51 Michael Pyne wrote:
> 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.
> 
Another recommended method is to put internal classes into foo_p.[cpp,h] 
files and make sure not to install foo_p.h