naming convention for internal methods

[Aaron J. Seigo]

hi all...

not wanting to start a huge conversation, but wanting pass this by people for 
brief and informed comment:

right now we have some methods which are internal to the API but can't be put 
in the Private class due to inherited classes needing access to them. without 
doing convulated things like inheriting Private classes and what not, i don't 
see it happening any other way as easily. kconfig has some examples of this 
right now due to maintaining compatibility.

so i'd like to suggest that when such a need arrises that we have a standard, 
and suitably ugly, naming convention for them so it is immediately 
recognizable as such a method. specifically, i'd like to make this is the 
standard naming notation for such methods:

     _internal_camelCaseName

they should reside in their own protected: block away from other normal 
methods just to make it even more obvious when reading headers.

they should never be in private:, since those belong in the Private class; an 
except for extraordinary life-or-death situations they should never be in 
public:.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/20070315/43318cfb/attachment.sig>