Right now, I am developing OpenGL bindings for the C# language (see the Tao Framework and OpenTK libraries) and I would like to make some suggestions about the format of the spec files in the next OpenGL versions, in the interest of promoting OpenGL to programming languages other than strict C and C++.
The current enum and enumext spec files contain some very useful information regarding OpenGL enums: enums are given real names (e.g. BeginMode enum, which contains the “POINTS”, “LINES”, “TRINAGLES” etc values). While this information is not used by the current (perl) generators when creating the official C headers (and indeed, C cannot distinguish between a const int and an enum), it can be used in higher level languages to generate type-safe bindings to the OpenGL functions. For example, in OpenTK the glBegin function is defined as “void GL.Begin(Enums.BeginMode mode)”, which will only accept the values found in the BeginMode enum (the check is done at compile time!)
This is extremely beneficial, as it not only protects from coding errors, but also because it trmendously increases programmer productivity as well as the discoverability of OpenGL functions (in most C# IDEs, typing “Begin(” will automatically bring up the list of possible parameters).
What I would like to suggest is that future spec files (be they xml- or text-based) retain the information on distinct enumeratations. The Mesa project has unfortunately dropped this information, and should the official specs drop it too, OpenGL in programming languages more advanced than C would suffer from C’s weaknesses.
One more thing that would be beneficial (but not strictly needed) would be the introduction of an “overload” directive in future versions of the specs. OpenGL functions that actually are overloads of each other (e.g. Vertex2d, Vertex2fv, Vertex4i etc. are all overloads of the imaginary function “Vertex”) would be marked as “overload [base function name]”, were [base function name] is the function name stripped of all decorations (i.e. “Vertex” would be the base function name of Vertex3f). While this “stripping” can be done programmaticaly using the current specs (something I plan to try soon), it would be easier and less error prone to have this “base name” included in the future specs.
Last, it would be nice if we had the source code of the official generators. There is some perl source code in the SGI repositories, but it seems it may not be the latest version.
So what do you think of these issues?
a) Will the enumerations be retained in future specs, or will they be dumbed down to “const ints”?
b) Is it possible/feasible to add an overload directive to some future spec files?
c) Should the source code of the official generators be made available?
d) Should there be a set of “official” C# OpenGL bindings? I am willing to maintain a working, up-to-date version if required.
e) Is there someone specific I could/should contact in the Khronos group regarding these questions?
f) Does anyone know where a current version of the gl.tm file can be found? The spec files are useless without known the mapping of new types (e.g. BufferTargetARB). (see Edit2 at the end)
For anyone interested, the source code for the C# generator is available in the Tao Framework source code (which generates low-level C-like bindings), and the experimental OpenTK library (which generates higher-level type-safe OpenGL bindings).
Edit2: It seems that you have to be a member of the Khronos group to access the official OpenGL implementation. This is extremely disappointing, since two of the core tenets of OpenGL - freedom and openness â€“ are not being followed.
At the very least, the source tree of the official implementation should be made publicly available. If this is not currently possible (and there is no compelling reason why it should not be), the up-to-date equivalents of the specification files found in the sample SGI implementation should be added to: http://www.opengl.org/registry .
I hope this matter is given the attention it is due.