<div dir="ltr">Jeremy -- I like the functor idea + first class modules: it is elegant. However I agree with Daniel's point about maintainability.<div><br></div><div>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.</div><div><br></div><div>Thanks for all of the help!</div><div><br></div><div>Trevor</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 10:40 AM, Daniel Bünzli <span dir="ltr"><<a href="mailto:daniel.buenzli@erratique.ch" target="_blank">daniel.buenzli@erratique.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le lundi, 20 octobre 2014 à 16:10, Jeremy Yallop a écrit :<br>
<span class="">> Yet another possibility: you can avoid the need to write C altogether<br>
> by defining the public interface as a module type, defining the<br>
> platform-specific struct definitions as implementations, and using<br>
> first-class modules (or the build system, if you prefer) to pick an<br>
> appropriate definition for the platform.<br>
<br>
</span>While Jeremy's approach is sound, I would advise against it from a maintenance point of view.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best,<br>
<br>
Daniel<br>
<br>
<br>
</blockquote></div><br></div>