[HOpenGL] OpenGLRaw naming convention

[Jason Dagit]

On Mon, Jan 16, 2012 at 1:16 PM, L Corbijn <aspergesoepje at gmail.com> wrote:
> 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...

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