DRAFT document on coding conventions in kde libraries

[Andras Mantia]

On Monday 06 March 2006 15:49, Kuba Ober wrote:
> > 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.

Maybe my wording was wrong. What I say that I support d-pointer classes 
as they are used right now: the private class itself is not inside the 
main class, but declared separately.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060306/e55ba97f/attachment.sig>