On Mon, 2008-07-21 at 09:34 +0200, François Perrad wrote: > Geoffrey Broadwell a écrit : > > fperrad: How do these bindings actually work? > There'll work with runtime/parrot/library/OpenGL.pir.
OK ... so what could be improved about runtime/parrot/library/OpenGL.pir so that you didn't have to write any bindings at all, or so that your bindings could be greatly simplified? So far, I'm seeing the following: 1. HLL access to the GL constants. At the very least, you should already be able to define your constant table using the generated constants in runtime/parrot/include/opengl_defines.pasm, rather than having to hardcode them all. Even better, this should all be wrapped up in an HLL-friendly way for you, but I've been looking for suggestions on how best to do that in a cross-HLL manner. 2. Namespace unflattening (glFoo -> gl.Foo, glutBar -> glut.Bar). That should be easy for runtime/parrot/library/OpenGL.pir to do, but may not be valuable to you if you already have to do everything else below. 3. All subs are marked :anon, and then manually added into a global LuaTable which appears to be reimplementing a namespace. Why? And if all Lua namespaces are created this way, does LuaTable implement enough of the Parrot namespace API that other HLLs will be able to work with Lua-implemented modules? 4. Ignore extra args to each function (which I'm just guessing is the purpose of the '.param pmc extra :slurpy' on every sub). Why do you want to do this? 5. All params are marked :optional (but don't have matching :opt_flag params) and seem required by the code. Again, why do this? 6. Argument type checking and conversion. This appears to be the "real" problem, though this seems like the exact kind of problem that Parrot was supposed to make easier for us. If you have to manually wrap every function in a cross-language library in every HLL because Parrot won't Do The Right Thing, that seems like a design flaw. 7. Simplified wrappers around some common functions. I've been thinking about creating some of these (most OpenGL wrappers for scripting languages seem to do this, to a greater or lesser degree). Whether it is worth it to try to do this in runtime/parrot/library/OpenGL.pir depends on how many HLL implementors are trying to get exact ports of existing bindings in the original (non-parrot) implementation of their language, and how many would be willing to share a common simplified binding. Anything else I'm missing? -'f
