GObject in GC implementation Plan

[Derek Atkins]

"Daniel Espinosa" <esodan at gmail.com> writes:

>> I don't want to create FUD, sorry. But you're right, I need to explain
>> in more details:

Thanks..

>> 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

Yes, I think we understand that we need to do that.  Using GObject
properties we could remove the need for qof_instance_init_data() by
moving those settings into the call to g_object_new().

>> * 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

I don't think it would be a major change.  I think it's possible to
change the underlying QofEvent implementation to use GObject signals,
and then slowly migrate from QofEvent to g_signal.  If we can make it
so that a single event emits both a g_signal AND the QofEvent, then a
single event would wind up calling both the signal handlers AND the
QofEvent handlers.

>> 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

This isn't hard, this is just busywork.  It's pretty straighforward
how to do this.  We can do it one object at a time.  Add the accessor
functions, then go file by file and convert the direct access to the
functions, then go and move the variable from the public to the
private interface..  Voila..  We've moved it without breaking the
code.

>> * 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.

"poliformic"?  Do you mean "polymorphic"?  I guess "poliformic" would
mean "multiple forms"?

Yes, the QofParam concept is similar to GType, but different..  And
yes, we're definitely going to have to rethink it a little, making it
more clear..

So, yes, we're going to need to think a little more on this.  I'm not
sure we could /just/ use the GObject Properties for this.  Maybe we
can, but even if we don't use GObject Properties I think that's fine.
Nothing says that we have to use GObject Properties.

>> * 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

Well, this was one problem with your branch (see my previous message
about trying to do too much at once).

Yes, changing the QOF Type system is DEFINITELY going to be a pain.
It's going to require some major re-thinking.  But perhaps we can
continue to use strings in some places, too.

> 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.

This isn't hard to do.  This just takes time to fix.  The easy way to
do this is to #define the existing API to the polymorphic API and then
we can slowly work through the code removing the usage of the old
APIs.

> 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.

You can thank Neil for that.  But yes, over time we can convert
everything to some standard API and just use that.

Again, this isn't HARD, it's just a lot of busywork.

So, really, the only HARD things to do are the QofParam and QofId type
issues.  Everything else is pretty straightforward.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available