From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Vollmer To: Rob Browning Cc: guile-gtk@sourceware.cygnus.com, gnucash-devel@gnucash.org Subject: Re: Taking the defs file issue Date: Wed, 15 Nov 2000 06:42:00 -0000 Message-id: <8766lp70xl.fsf@zagadka.ping.de> References: <200011122001.OAA18311@cs.utexas.edu> <878zqoeulm.fsf@raven.localnet> <87wve83eoa.fsf@zagadka.ping.de> <87k8a8d70j.fsf@raven.localnet> X-SW-Source: 2000-q4/msg00029.html Rob Browning writes: > Marius Vollmer writes: > > > I quite strongly disagree with this. In my view, the functions > > exported to the Scheme side must not be not be `dangerous' in the > > sense that a pilot error can not lead to memory corruption, memory > > leaks or similar. > > Well, I suppose this depends on your perspective, and what you want. > If you want to create a tool that lets you do from scheme the same > things you can do from C with a given C API, and if you want to > provide a way for people to *quickly* wrap *existing* C APIs without > having to write a lot of additional glue code, then I think it's going > to be *very* difficult to avoid the "dangerous" things you're talking > about. Yes, very true. I guess my main point is that I don't want guile-gtk to degrade when switrhcing to g-wrap. That is, the work of avoiding "dangerous" things has been done (more or less) and I don't want to lose this. Well, I might argue that providing a tool that makes it really easy to do dangerous things is not a good thing, and that we at least should put up warning signs all over the place that the quick solution is not necessarily the best solution and that people should spend a moments thought on how they can make the bindings safer etc. > As you pointed out, you had to change Gtk+ to make it safe, and in > general, requiring universal safety may often require the > wrapper-spec-writer to add "safe functions" on top of an existing C > API before publishing to scheme via g-wrap. Yes, and the problem with Gtk+ was that you could not add these safe functions on top of the existing API. That would have been nice. >From a broader perspective, makeing an existing API safe for wrapping from Scheme should almost always be a significant improvemt of the API itself, independent from Scheme. A non-trivial client of the API should have most of the same problems that a Scheme binding has when it comes to memory management (type issues are probably different). For example, ref counting in Gtk+ was inadequate, not just for Scheme, but for any non-trivial program. You could just not rely on it because it interacted badly with the functionality of the objects (for GtkObjects) or wasn't there at all (for GdkFonts etc if I remember right). Cleaning up reference counting made the Gtk+ API better in my view, independent from the fact that I needed the improvement for the Scheme bindings. Anyway, we can not always change existing APIs and I got lucky that the Gtk+ people have listened to me, but I'd still like bring this topic up. I also see it as a kind of education. There are just too many crappy APIs out there that just don't need to be that way. API design is significantly harder than mere coding and I'm unhappy with most of the APIs. Just look at libc. Horrors! :-) Ok, well, I guess I don't need to lecture you, but I couldn't help myself. > However, I still worry that it may be hard to come up with a safe and > efficient scheme side interface for every C API without a lot of > effort, and in some cases, just having the API might be better than > having the perfect one. Yes, but when the API allows a safe binding, g-wrap should be prepared to generate one. This is probably mostly an issue of documenting what exactly a safe binding would be. How to bridge the Scheme / C gap. I feel that for all my rambling, I should really sit down and write such a thing...