GObject in GC implementation Plan

[Daniel Espinosa]

2007/4/12, Daniel Espinosa <esodan at gmail.com>:
> 2007/4/12, David Hampton <gnucash at love2code.net>:
> > On Thu, 2007-04-12 at 14:06 -0500, Daniel Espinosa wrote:
> >
> > > I can understand why you feel that; the reason is that I don't think
> > > that convert QOF to GObject will be a good idea because its
> > > implementation doesn't allow it, you'll never have a full GObject
> > > system if you insist to use QOF.
> >
> > You keep making that statement, but you haven't explained what you mean
> > by it.  Why can't we eventually migrate to a full GObject, what will be
> > missing, and what will that mean to the project?  Please either explain
> > yourself, or stop spreading what (at this point) I can only call FUD.
> >
> > David
>
> I don't want to create FUD, sorry. But you're right, I need to explain
> in more details:
>
> QOF to GObject: The easy part
>
> * Convert the base object QofInstance to GObject, done by Derek.
>
> * Migrate to full compatible Ref/Unref procedures, will be done in the
> next steps for all objects, just need to move some code, even this
> step can't be stablished if you don't use Properties, see my
> explanation about why I have a "book" property in QofInstance
>
> * Signals can be added, but need a major change in the way QOF works
> in events, but need to modify the way to call the events, and maybe
> add some signals directly in the Objects
>
>
> QOF to GObject: The Hard Part
>
> From the less dificult to the more:
>
>
> * Change direct access to variables and add API functions in the
> Objects; if GC (not QOF) uses procedures to access the variables in
> QOF's objects could be more easy, but they have direct access to the
> variables using object.inst.entity->do_free, for example, then you
> can't move variables to be protected like in GObject, becouse you need
> to add the API function and modify lots of code lines
>
> * QOF use QofParameters, are like Properties, but they don't use a
> poliformic procedure, use a string based to know the parameter type,
> but worst it use strings to know if a paramenter is a variable in a
> object type, this is not sopported by GType system, you can know the
> object or data type, but no if this is a variable in a object.
>
> * Change the Type system is a great problem, I have worked to do so in
> my first effort, but found lots of lines and procedures to change and
> there's a link between QofParameters that use static strings not
> dinamically assigned integers in GType, this will require to re-write
> most procedures and code in the whole GC
>

Sorry I send it before finish...

QOF needs a clean up

QOF doesn't use polimorfic (or its realy rudimentary), then the
derived classes difine its own functions with the same function but
diferent name, the derived class doesn't use its father's API, and the
Class concept is diferent from GObject's one, then needs to modify the
"new way" in several code lines and procedures.

QOF API have a lot of deprecated code, lots of types and functions
re-#define in GC, it includes the documentation in the headers files
Gtk/GObject/GLib uses other documentation system where you can see a
clean headers files and a few documentation in the c files. This code
is realy dificult to read and takes more time if you want to see how
QOF work and not what the documentation says.


I'll try to find the links to the code to document all my comments,
but take some time, please be patience.


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)