Object System

[John Ralls]

On Sep 20, 2011, at 1:30 AM, Christian Stimming wrote:

> Zitat von John Ralls <jralls at ceridwen.us>:
>> [...]
>> 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