naming convention for internal methods

[Thiago Macieira]

Aaron J. Seigo wrote:
> without
>doing convulated things like inheriting Private classes and what not, i
> don't see it happening any other way as easily. 

There's another solution that doesn't involve inheriting the Private 
class: make the Private class protected.

As long as you have access to the Private class's definition (either 
because it's in the same .cpp or because you can include the _p.h file), 
you can call the private's methods easily.

>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

Why not _k_camelCaseName?

Anyways, it should be suitably ugly for users of the API never to think of 
calling those.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/0a1b3354/attachment.sig>