naming convention for internal methods

Aaron J. Seigo aseigo at kde.org
Thu Mar 15 17:53:42 GMT 2007


On March 15, 2007, Thiago Macieira wrote:
> 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.

yeah, it's not that the Private class is declared private: (or protected: for 
that matter) that's the issue. it would mean having to have separate headers 
for them, the Private class may need to know what its associated object is, 
etc... requires a fair amount more changes to the existing code base that i'm 
not prepared to do personally right now =)

> >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?

well, "_internal_" is self documenting. "_k_" is just cryptic.

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

yes

-- 
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/4f92ae78/attachment.sig>


More information about the kde-core-devel mailing list