Jeremy -- I like the functor idea + first class modules: it is elegant. However I agree with Daniel's point about maintainability.
If I use the allocate w/ a c function that returns the size of the struct I will be good to go. Then have ctypes reference public fields and make strong wording in the implementation to never allocate a ctype struct using make. I think this is a solid plan. Thanks for all of the help! Trevor On Mon, Oct 20, 2014 at 10:40 AM, Daniel Bünzli <[email protected] > wrote: > Le lundi, 20 octobre 2014 à 16:10, Jeremy Yallop a écrit : > > Yet another possibility: you can avoid the need to write C altogether > > by defining the public interface as a module type, defining the > > platform-specific struct definitions as implementations, and using > > first-class modules (or the build system, if you prefer) to pick an > > appropriate definition for the platform. > > While Jeremy's approach is sound, I would advise against it from a > maintenance point of view. > > These platform specific fields are labelled as *private* fields in the C > interface which means that each time libuv makes a new release you will > have to manually check that your description of the c struct in your ctypes > is still accurate. > > If the libuv project is well managed you can assume public field changes > will be documented in release notes so you'll be warned when you need to do > changes. However changes to these privates fields are unlikely to be > described so it will be more work for you in the long term. > > Best, > > Daniel > > >
_______________________________________________ Ctypes mailing list [email protected] http://lists.ocaml.org/listinfo/ctypes
