On Wed, November 16, 2011 12:40 am, John Ralls wrote: > > On Nov 15, 2011, at 9:16 PM, Derek Atkins wrote: > >> Hi, >> >> On Tue, November 15, 2011 11:17 pm, John Ralls wrote: >>> >>> On Nov 15, 2011, at 7:24 PM, Derek Atkins wrote: >>> >>>> Hi, >>>> >>>> This depends on your definition of 'wrapped.' In general, C >>>> structures >>>> are mapped to Scheme as opaque pointer objects, which requires using >>>> getters/setters from guile to manipulate the object. For example, you >>>> can't just do Account->desc in scheme, you need to use >>>> (xaccAccountGetDescription acc). >>> >>> Has anyone ever tried using the gnome 2 Guile bindings and whatever is >>> the >>> g_object_get mechanism from Guile? >> >> Probably not, because I don't think it existed in a sufficient maturity >> the last time we did a scheme generator migration (g-wrap -> swig). >> What >> is the current maturity of these bindings? How supported are they? Are >> they being actively developed and maintained? What does it buy us that >> we >> don't already have? > > It's different from gwrap or swig (that would be gobject-introspection, > which doesn't appear to be well supported, > unfortunately). Rather, it is a guile "library" like slib or ice-9 that > permits calling GObject functions without explicitly > wrapping subclasses. It would let us simplify the API by e.g., not having > to export explicit getters/setters, directly using > GObject memory management, and so on. > > (FWIW, Python integration with both GObject and GObject-Introspection is > both extensive and very actively developed. Were we starting now we'd have > to be nuts to pick Guile over Python.)
If we were starting now we'd probably not be using C at all (and I'd argue whether or not we should be using gnome/gtk/glib, either). But alas we have over a decade of legacy code that's had thousands of man-hours of work to get us where we are, and it would be a shame to give all that up. We can play the "what if" games or think about how we could have done things better if we could start over, but I feel it would be a better use of our time to look forward instead of looking back. > > Regards, > John Ralls -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel