Object System

[Christian Stimming]

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.

Regards,

Christian