DRAFT document on coding conventions in kde libraries

[Kuba Ober]

> I wanted to write the same, but in case of the libraries, it makes sense
> to have a common look, at least for the interfaces, and that includes
> if:
> - the d pointer classes are private or not (I support non-private ones)

If the d pointer classes are not private, there's no point in having d 
pointers, right? A private dptr class lets you modify the implementation 
without breaking BC. A protected/public dptr class doesn't allow you to do so 
-- any changes in the dptr class will break BC, since application code can 
now depend on the dptr class.

An exception would be a case where the dptr class is protected, but the parent 
class is not designed to be derived from in the application code (and it's 
documented to be so).

Cheers, Kuba