Re: Proposal for a collection API in glib



On Fri, Jul 18, 2008 at 9:33 AM, Gustavo J. A. M. Carneiro <gjc inescporto pt> wrote:


Sure, but you are assuming a scenario where g-i already has complete and
accurate metadata about the library APIs.  Assuming that scenario is not
very reallistic, I think.

I believe the goal is to fix those header files. 

Long term, as I understand it (just digging in a bit to g-i myself now) what will be great about g-i is that it will ensure that people coding in C create bindable interfaces, rather than the most convenient interface for C.  We slip on this right now because .h -> .def is an asynchonous, manual process.  Put simply, if you create a new method with no metadata, it won't break the build.  With g-i, it *will* break the build because it's integrated into the library build process.
 
 At the end of the day, it will be people doing
language bindings doing the heavy lifting and figuring out, possibly
from the .c files (memory management semantics often are not clearly
documented), and folding back that information into the metadata. 

Again I think the point is we want to move this burden to the library authors (supported by the authors of all language bindings), rather than redundantly duplicating it in each binding.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]