[haXe] haxe/neko libraries

[Nicolas Cannasse]

 > compilation (haxe -neko) of the current gl wrapper takes 10-15s, though.

Yes, if you have a lot of code, it will generate a big Neko intermediate 
file, and will takes time to compile. That's because haXe is first 
generating a neko file on disk and then calling the neko compiler. I'll 
try to improve this in future releases.

> maybe wrapping all the GL globals into enums, or a different technique to split that beast, would speed it up? obviously, if i wrap all the different functions and enums of GL into a more object-oriented haxe model of gl, i'd need to load only the classes (and thereby lowlevel neko functions) that interest me-- i'm just thinking loudly, sorry.

Yes, that would be interesting to have something more strictly typed.
OTOH, enums are haXe-specific and their runtime representation might be 
subject to changes, so it's not yet very easy to build them from the 
Neko C FFI.

Using objects instead of hundreads of functions might make sense, but 
provides less security since existance/arguments number are not checked 
at load-time but at call-time. That's a matter of choice.

> having the full GL api available (and after all, it is kinda "flat") from haxe/neko would be sexy, though. so any ideas are appreciated.

You might have a look at LablGL, it's an OGL wrapper for OCaml which is 
using some interesting architecture, although I haven't studied it a 
lot, it might be nice to see another wrapper example - although haXe and 
OCaml types system are different.

Nicolas