John,
> ---------- Forwarded message ---------- > From: John Ralls <[email protected]> > To: Christian Stimming <[email protected]> > Date: Tue, 20 Sep 2011 07:01:42 -0700 > Subject: Re: Object System > > On Sep 20, 2011, at 1:30 AM, Christian Stimming wrote: > >> Zitat von John Ralls <[email protected]>: >>> [...] >>> My feeling is that the first option, finishing the GObject conversion, has >>> the lowest risk. I can start in on it >> >> Thanks for the exhaustive summary. Yes, I agree with pretty much all of your >> points. Yes, I've thought about these issues every now and then as well. >> Yes, the mix-up of different object systems is a major issue in the engine. >> >> And: Yes, moving all of our "business logic" ("engine") objects into GObject >> seems to me the best compromise in terms of where to spend our current >> effort. >> >> I thought about adding C++ wrappers for our engine objects, but ones that >> use glibmm's C++ wrapper around GObject. Using those will ensure that >> GObject's memory management is properly mapped into the corresponding C++ >> object, so that the C++ object behaves correctly. (Cutecash's C++ wrappers >> do not behave correctly - they will crash as soon as a C object is deleted >> but the C++ wrapper is not and is being accessed.) If I get around to this, >> it means any effort on the GObject'ification of the engine will also give us >> appropriate C++ wrappers in addition to the C objects with very little >> effort. >> >> Also, from my understanding having proper GObject objects enables better >> wrappers into python or ruby - or at least that was one of GObject's claimed >> advantages. But as you said this might have its own issues and we should >> currently decide on the basis of what gives us the most benefit with our >> current C code. >> > > No surprise to me that your C++ wrappers crash. I suspect that the only thing > that keeps Gnucash from crashing routinely is that everything is instantiated > at startup or at creation (for, e.g., a new transaction) and not destroyed > until the book is closed... after which there aren't any attempts to access > the objects. > > GObject, once we can move to 2.26, (RHEL6 and Debian stable are currently on > 2.24), works with gobject-introspection, which should allow us to dump SWIG. > But that only works if the objects are truly GObjects, so that setting the > ref count to 0 actually destroys the object. > > Regards, > John Ralls > I agree with your suggestion as well and would like to participate in your effort to move this forward, in parallel with other smaller functional items I would like to work on. Regards, Alex _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
