[ocaml-ctypes] Defines, and Structs with platform-specific fields

[Trevor Smith]

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 <daniel.buenzli at erratique.ch
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/ctypes/attachments/20141020/7fa24d55/attachment.html>