Re: [HOpenGL] OpenGLRaw naming convention

On Mon, Jan 16, 2012 at 1:16 PM, L Corbijn wrote:

On Mon, Jan 16, 2012 at 8:55 PM, Jason Dagit wrote:

...

On Mon, Jan 16, 2012 at 3:19 AM, L Corbijn 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...

Great :)

Lars

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

I've tried several and while cmdargs gives you an API where you don't have to repeat yourself, it uses unsafePerformIO under the hood and as such I tend to only use it for toy programs. When the code is going into production getopt is the one I prefer (and same goes for most of the folks at work). http://www.haskell.org/haskellwiki/GetOpt I hope that helps, Jason