From kde-core-devel  Wed Jan 03 15:46:06 2007
From: Olivier Goffart <ogoffart () kde ! org>
Date: Wed, 03 Jan 2007 15:46:06 +0000
To: kde-core-devel
Subject: Re: private slots
Message-Id: <200701031646.11572.ogoffart () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116783927520884
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart4355142.sm4vX1PzJY"

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

Le mercredi 3 janvier 2007 16:05, Simon Hausmann a =C3=A9crit=C2=A0:
[...]
> And of course in general I suggest not to have any private methods in our
> public API at all. Putting it into your d-pointer gives you more
> flexibility in the future to change the implementation. There is really no
> good reason for exporting private functions.

=46rom http://developer.kde.org/documentation/other/binarycompatibility.html

You can ... remove private non-virtual functions if they are not called by =
any=20
inline functions.

So this still give us the possibility to change the implementation.

I think that choosing to have private member in the class itself or in the=
=20
Private class is a matter of preference and choice.

Anyway, if that document is wrong, then, yes, we must do that in all our=20
classes (and correct the document).

=2D-=20
Gof

--nextPart4355142.sm4vX1PzJY
Content-Type: application/pgp-signature

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

iD8DBQBFm8/Dz58lY8jWrL0RAgvUAJ9Y9iAGPfTPssBb1GTHOVzAPOwEeQCfePvl
gdkuAOJ/YMLR8cEDMDLLZQU=
=K4uB
-----END PGP SIGNATURE-----

--nextPart4355142.sm4vX1PzJY--