[Bf-committers] Final Design of Basics (render api)

[Aaron Moore]

Hi again Campbell,

> Could you have some kind of rationale behind the naming of functions?

My rationale up to this point was "reads like english," but you're
right I should come up with a more systematic naming scheme. Also, for
readability I have been using the convention of no abbreviation. Code
is read more often than written, so I really want to make this API
readable, and clear in whatever ways I can. A few extra characters
never hurt anyone.

Here's an attempt:

--- callbacks, plugin defined structures ---
no prefix, CamelCase for types, underscores for names.

--- enums ---
Rapi_TYPE - Rapi_DATATYPE
Rapi_OBJECT_VALUE_NAME - Rapi_GEOMETRY_POLYGON_MESH
// organization is less obvious with these than function names
// but readability would diminish if I did VALUENAME instead.

--- handlers types ---
RapiType - RapiObject, RapiVertex, etc.
// CamelCase for types, underscores for names as a general rule.

--- functions ---
Rapi_Object_OperationCamelCase - Rapi_Object_GetNext()
// 3 sections divided by underscores: prefix, data, operation.
// I think this is reasonably organized and readable.

I'll go ahead and put these in the render api page, because I think
they're good enough to satisfy, anyone is free to suggest further
changes.

Aaron