> hey nicholas, > > i'm having progress with my OpenGL wrapper, i'll publish soon. > > one question tho- opengl uses plain double* and int* a lot. i have no problem > in doing a simple neko library to allocate/read/write those, so they are > createable and accessible from neko (and thus haxe). what i really want to do > tho, is to share the kinds i define for those between libraries (GL and GLU > for example, but also others). > > now, the ad-hoc way to do this of course is to make a new shared library > (say, "cptr"), that exists both as a .ndll providing the access/alloc > functions, and as a .so to link the other libs (GL.ndll) against. then i can > DECLARE_KIND my kinds in cptr.h, and DEFINE_KIND them in libcptr.so, against > which both cptr.ndll and GL.ndll will link to have access to the kind. > > tho i am thinking that these types are so fundamental and appear in libs > again and again that it would be nice to be able to use them without the > additional burden of another shared lib. so- what do you think about defining > them as constant integers instead of using the memory address of a symbol? or > is this too ugly design-wise? if not, should they probably be defined in > neko.h? or at least be part of the standard dist?
That's a good question. I actualy already thought the same about the "hashtable" and "int32" types. Should they be declared in libneko ? in the standard library ? where should the exported api go ? I made the following choices : - int32 is declared in libneko, and has only very minor support (printing). It's mainly used in Std but is "standardized" so the same "kind" can be used in different libraries. Actually, the only reason it's not in Std is because the logic of Neko is not to link libraries together. You're supposed to only use libneko. - for hashtable it's same reason, I wanted the internal structure of hashes to be usable for all Neko libraries, hence it needs to be in libneko and not is std. Since libneko does not export any primitive (only builtins), hashtables are then manipulated with builtins. Actually, if any library could "build" a "kind" from an identifier, it would somehow decentralize the need to link against a library. To use its declared types one would only need to agree on internal representation. OTOH that would mean that two kinds having the same name but different meanings would conflict since they would have the same identifier. I'll try to think about it. Maybe reducing current constraints on abstract kind declaration would be actually a good idea. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
