lablgl (was Re: [Caml-list] Stdlib)

["Daniel Bünzli" <daniel.buenzli@epfl.ch>]

Le 1 nov. 05 à 01:07, Jonathan Bryant a écrit :

> On another note, I would love to do this other project in OCaml,  
> but it
> is OpenGL intensive (read: based) and LablGL drives me nuts.  The  
> named
> argument thing drives me up the wall because it's more information  
> that
> I don't want to have to learn and internalize.

Besides the fact that labels can be omitted, I think this is an  
unfair criticism and that it is actually better to write the labels.  
Opengl C functions can have up to 11 argument (e.g. glTexSubImage3D,  
not bound in lablgl), if you use this function you will have, labels  
or not, to look up its documentation. You can see the advantage of  
labels once you are reading your code looking for a bug. If you don't  
write the labels you will have to read again the documentation to  
check that you passed everything at the right place, with labels you  
needn't.

These bindings are very carefully done (the "meta-programmation" of  
glue code is worth having a look if you once have to do bindings) and  
the interface is quite elegant. The only critique I have about the  
library is that it doesn't define everything in a single module Gl  
but scatters functions in different modules whose prefix doesn't  
necessarily match the prefix of the C function name. For example :

- glLoadMatrix is GlMat.load
- glLogicOp is GlFunc.logic_op
- glPixelStore is  GlPix.store.
etc.

This non-obvious name mapping makes it harder to learn the api and to  
port C OpenGL code samples. I don't understand this design decision,  
especially because, in the end, the documentation you need to consult  
is the C api documentation and therefore there should be an obvious  
mapping between C and ocaml names. Defining a single module Gl so  
that a C function name glDipDap is trivially mapped to Gl.dip_dap  
would be much more productive for the programmer.

Daniel