RE: [Plib-devel] PLIB developers needed.

[Dave M. <Dav...@dy...>]

Steve wrote:
> There is an element of trust here.  I obviously have to give up a
> measure of control - and yet trust that someone whom I give write
> access to isn't going to make a horrible mess of the architecture.
> 

What follows are a few things I've learned working on PLIB.  If you look
through the archives of this mailing list you'll find discussion and reasons
for them.

1) coding conventions
2 space indent
for public symbols in PLIB module 'XX'
(where 'XX' is: SL, SSG, SG, PU, FNT):

#define's, enum tags -- XX_ALL_CAPTIALS
variables -- all_lower_case
functions/classes/structs/typedefs -- xxMixedCase

for private functions, use all_lower_case unless they would pollute the name
space in which case you should use _xxMixedCase
(note the leading underscore).  if a variable pollutes the name space, use
_xxMixedCase.

2) don't use C++ exotics like STL, templates, exceptions, operator
overloading, and iostreams to make porting easier.  if you love that kind of
stuff, you can always wrap plib in your app code.

3) don't add dependencies.  PLIB requires OpenGL and optionally GLUT.  this
is an important and valuable design goal of PLIB.  It sure made it easier to
get PLIB running on a game console because I had to implement a subset of
just *one* API (OpenGL) for the native architecture.
http://www.pond.net/~davem/tinylib

4) For any major change, please consider posting to this list *first*.
Other developers may have a more elegant method of implementing the same
thing or already have a patch that they didn't think anyone else was
interested in.  Perhaps the major change you are thinking about does not
belong in PLIB at all and would be better off in an auxilliary library or
example.

--Dave