[HOpenGL] OpenGLRaw naming convention

[L Corbijn]

On Mon, Jan 16, 2012 at 8:55 PM, Jason Dagit <dagitj at gmail.com> wrote:
> On Mon, Jan 16, 2012 at 3:19 AM, L Corbijn <aspergesoepje at gmail.com> wrote:
>> Hello HOpenGL,
>>
>> While working on my OpenGLRaw-generator which is getting quite good
>> (current OpenGL compiles with minor changes) I've come to wonder/worry
>> about the current naming convention of Raw.
>>
>> The current naming scheme of OpenGLRaw can best be described as, try
>> to remove the vendor names (NV, ARB, etc. suffixes) unless it will
>> result in a conflict. To give two examples, MultiTexCoord2dARB ->
>> MultiTexCoord2d, as there is none defined otherwise, while
>> glPrimitiveRestartIndexNV keeps it's name as glPrimitiveRestartIndex
>> is a different function.
>>
>> When generating code I've come across a few nasty disadvantages with
>> no obvious solution in this scheme.
>> 1. What to do when two or more vendors have the same enum/function
>> which should be promoted to the one without vendor name.
>> 2. The mixing of functions with and without vendor name, e.g.
>> glPrimitiveRestart, glPrimitiveRestartIndexNV from NVidia's
>> PrimitiveRestart extension.
>> 3. Breaking changes, what if a new extension or even a new OpenGL
>> version adds a different enum/function with the same name (without
>> vender part), as the striped name collides the extension must be
>> re-added leading to some code breaking (maybe even silently!).
>> The only advantage I see is that two enums/functions who differ in
>> name also differ in value/implementation.
>>
>> Therefore I would like to know what people think about the current
>> naming convention, and whether it would be a major issue to change it
>> (probably to keeping the vendor names everywhere).
>
> Two ideas:
>  * What about having the "RAW" api keep the names verbatim and other
> layers on top rename things?  Basically, defer this decision to a
> different point.

So not renaming anything, that's simple, see the noNameStrip branch.

>  * Collect all the Foo versions in a Foo module and then remove the
> Foo from the names inside the module.

This is also not so hard and is implemented in the allNameStrip
branch. Though this creates conflicts in the 'vendor' module (at least
I got one from the ARB module using e.g. TEXTURE_BLUE_TYPE with and
without suffix), which of course can be fixed by some extra code. This
extra code is already in the develop branch (the renameValue stuff)
but is also very resource hungry at the moment.

> Does that make sense?  Are either of these possible with your bindings
> generator?

Both options make sense and that makes the decision a harder one.
Personally I prefer the first because you get what you asked for (and
you can ask what you need not for something else). As for the
generator, I wouldn't program if I didn't like to tackle problems...

Lars

P.S. Does somebody have a good suggestion on a library for
command-line-options parsing?