GObject in GC implementation Plan

Derek Atkins warlord at MIT.EDU
Tue Apr 3 08:19:56 EDT 2007


Hola...

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

>>   2) Implement GObject refcounting.  I think this might be able to go
>>      on an object by object basis, but I don't know for sure.  But as
>>      we get working state, perhaps merge into trunk.
>
> When you have a GObject derived class, even if doesn't follow the
> automatic GObject's construction/destruction feature, you have
> refcounting. Actually we can leave, and we must in order to keep the
> changes SMALL, the QOF construction/destruction just keep in mind that
> when create an object call g_object_new and when destroy call
> g_object_unref.

Sorry, what I meant here was that we don't need to USE g_object_ref()
or g_object_unref() to hold additional references.  Of course GObjects
themselves have ref-counting, but in stage 1 I think we can just live
with a single reference held by the engine.

[snip]
>> I'm not sure I agree here.   I think that if you break it down
>> into truly the smallest pieces then it WOULD be mergible.  See
>> what I wrote above.
>>
>> For example, to GObjectize the GnuCash Account object in this way
>> would require only minor changes xaccInitAccount(),
>> xaccMallocAccount(), and xaccFreeAccount().  In particular:
>>
>> xaccInitAccount():
>>   Remove qof_instance_init() because it's no longer needed.
>
> if you want  SMALL changes you need it for the early steps.

Sorry, you're right.  We do need to keep qof_instance_init().  I
just changed the name to qof_instance_init_real() so I can find
all the places where it's used.

>> xaccMallocAccount():
>>   change g_new0() to g_object_new() to create the "GncAccount" object
>>
>
> Ok and keep all the init process of this object.

Correct.

>> xaccFreeAccount():
>>   remove qof_instance_release() because it's no longer needed
>>   change g_free() to g_object_destroy() to destroy the gobject.
>>
> You need to remove g_free and the end of the object destruction, and
> keep qof_instance_release to call there g_object_unref.

Why?   Why do we still need qof_instance_release()?  Can't that
work be done in the finalize() call of the GObject?

I would think that we could just change g_free() to g_object_unref()
and let the qof_instance_release() code get executed from within the
unref calls.  Is this NOT the case?  Why wouldn't that work?

>> That's it (well, except for the GncAccount GType hooks).  I think this
>> is fairly straightforward and could be done with minimal impact.  I
>> don't even think you need to change anything in the Account headers or
>> account structure.  Once you change QofInstance to be based on GObject
>> everything else is just inherited so only these minimal changes are
>> required to "get it working".
>
> Realy change GncAccount as a GObject isn't dificult, is just work, but
> the real problem is QOF it selft.

What's the problem?

>> Now, you might argue that this really isn't using GObject properly,
>> and I'd agree.  See above about doing it in multiple steps.  Doing it
>> THIS way we get a working system sooner, and then we can migrate to
>> each gobject feature over time, one feature at a time.  It means we
>> have a small set of changes that we COULD merge into trunk and would
>> reduce the risk of failure.
>>
> I can see that we can implement GObject as the base class and add
> signals, but that's all, this features are "easy" just need code; all
> other features in QOF like the type system, QofParamenters, Class
> system and QofQuery will be realy dificult and may be imposible to
> changes with out a great CHANGE in the base code, they will need a
> COMPLETLY re-write, becouse they're far diferent from GObject, not
> exactly, equivalent feature.
>
> A great problem is the actual code; it uses its parent objects
> directly, don't use functions, and they don't use the actual API even
> when it is avairable, this make VERY SENSITIVE the code in any change
> made in the access methods.

Yes, signals are easy..
But we can think about the other GObject features over time.
First let's get everything to be a GObject, get refcounting,
and then get signals migrated.  THEN we can think about the
more complicated QOF features.

A complete re-write is fine, over time.  But not all at once.
Take a look at "branches/gobject-engine-dev-warlord" for an
example of what I mean by small steps.  And even what I did
I got admonished for actually performing the renames instead
of using #defines().

But this is what I mean by "commit early, commit often".  Indeed,
the branch compiles AND passes "make check" right now.  Granted,
I plan to continue to make changes to it shortly that will break
it for a while, but it shows that you CAN make steps that wont
break the code.

My next commit to the branch will convert QofInstance to actually
using GObject, but this will break the build until I get everything
converted.

[snip]
>>    gint foo(QofInstance* inst)
>>    {
>>       ...
>>       Account* acc = (Account*) inst;
>>       ...
>>    }
>>
>> ALL of this code would be broken by this approach.
>>
>
> Un less for the Account object that's not a realy great problem, it
> hasn't that cast, the code use direct access to the instance and use
> QOF_INSTANCE when convert, I have done this changes for this object
> and it compiles know with out warnings.

How does "QOF_INSTANCE()" convert a QofInstance* to an Account*?
Please re-read the code snippet above.

[snip]
>> I think these are some major disadvantanges.  I still like options
>> #1 or #2 (tending towards #2) with the caveats that we make minimal
>> changes like I point out above.  Enough to get it to work even
>> though we don't use the full extent of gobject functionality right
>> from the beginning.
>>
>
> I can see the point will be to work on QOF, but please see at the
> code, it will be realy imposible to change to use GObject features in
> the future becouse it is far to be compatible with GObject in many
> ways.
>
> We can continue in try to use GObject as the base class, taken any of
> the steps above, but keep in mind that will be limited and maybe never
> be completly changed to GObject.

That's fine.  If we never use all of GObject, that's okay.  Or
maybe over time we'll have small projects to re-implement each feature,
one by one.  Each time we migrate a QOF Feature to GObject it will
be a semi-major undertaking..  But that's okay.  We just need to
do it one step at a time, one feature at a time.

> I'm preparing the document where I'll describe a new way to get
> advantages from GObject to get access to other external applications
> to the GC's data in the actual XML format or databases, by creating a
> GObject based library  .

I don't care about such a thing.  I can't answer for the other
developers, but I suspect that most of them don't think this is
necessary or required, either.

-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


More information about the gnucash-devel mailing list