GObject in GC implementation Plan

[Daniel Espinosa]

2007/4/3, Derek Atkins <warlord at mit.edu>:
> 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?

See bellow...

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

THANKS! If you're working on this project is great and way to advance
more quickly.

But you know more about QOF that any other in the project; you need to
try to do the changes your selft and find why it's so dificult and
maybe a lossed time to work in convert QOF in a PURE GObject over
time.

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

I have made that changes for Account object, but you don't want to see the code!

> [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 think we can save time in to use GObject creating a library that
wraps the actual QOF and GC functionalities.This could help to
"translate" the actual GC code to use this new library. Even can help
others (like me) to try to implement the same GC's functionalities
using other PURE GObject library other than QOF, in my case GDA.

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

I don't think this is necessary or required, I think this is a
convenient way to go.

See my next email about the new library.

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