GObject in GC implementation Plan

[Daniel Espinosa]

2007/4/12, Derek Atkins <warlord at mit.edu>:
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
> >> I think we have a major communication issue here...
> >
> > Yes we do...
>
> Well, we should work on that.
>

Ok great!

> >> qof_instance_release()
> >> really doesn't do all that much interesting, and I don't understand
> >> why that work can't be done in the QofInstance dispose() and finalize()
> >> class functions.
> >>
> >
> > It's clear that you can move the code to dispose() and finalize()
> > functions, but you need to be shure that other derived objects (not
> > GObject jet) finalize correctly its base class. Are you sure your
> > branch do this correctly?
>
> Of course I'm sure.  See lib/libqof/qof/qof-gobject.h.  The base
> type definition always call the local dispose() or finalize() and
> then chain up to the parent object's dispose() or finalize().
>
> Contrary to popular belief, I /DO/ understand how gobject works
> in general.  I admit that I might not be completely familiar
> with every last detail, but I do understand the high level
> concepts.  And I HAVE written GObject-based types before.
>
> [snip]

I'll see your code and make comments or propouse a PATCH if apply.

> > If you read my comment: YOU don't want to change too much then that's
> > why I sugest to keep this functions; the thinks you are done in your
> > branch more or less is the SAME I've done in gobject-engine-dev
> > branch: move the init process to init and dispose functions. But the
>
> Well, it's a lot less than what you did..  And the tree continues to
> work build and actually work.  THAT was the goal for step 1.  Get the
> initialization moved over and GET IT WORKING.  Your branch still
> doesn't compile, let alone work.  The reason it fails: you tried to do
> too much at once.  Not only did you move the base initialization, you
> tried to move the init/dispose/finalize code and add properties all at
> once, instead of doing each step separately.
>

That's why I started a new branch.

> > problem is that this functions you can't send parameters like the
> > QofBook, then the initialization process doesn't work, that's why you
> > still need to call qof_instance_init_data (in your branch) to call
> > qof_entity_init().  In my branch, I've created a "QofBook" property and
> > when you create a new derived object you call g_object_new
> > (GNC_object_TYPE, "book", book), then the init process is done as you
> > have in your branch and the book property is set inmediatly. When you
> > set the book you set the GUID's object.
>
> Yes, I understand.  And adding that property is another step in the
> process.  But it's a SEPARABLE step.  It didn't have to be done
> the first time through like you did.   Yes, it's something that DOES
> need to happen, but it didn't have to happen in the first step.
>
> > But don't lose in my details, do the thinks as you think is the better.
>
> I think we both want the same thing in the end.  I think you need
> to take much smaller steps to get there, steps like I took.  I was
> HOPING that showing you by example would help you understand what
> I meant by small steps.  I was hoping that you'd see "oh, THIS is
> what you meant by small steps" and be able to work from there
> taking similarly small steps along the path to the end that we
> both seem to want.
>

I'm not sure that convert QOF to GObject is the better way, but Ok if
I can help, I'll do.

> [snip]
> > See other projects use Anjuta to create GObject templates, and you'll
> > see what I mean.
>
> None of the gnucash developers use Anjuta, so that's not a useful
> statement.  I'll point out that Anjuta isn't the only way to
> develop, and I think that the current GnuCash code conventions
> trump Anjuta.   Still, can you point me to a sourcefile that
> shows what you mean?
>
> [snip]

Anjuta was just a tool to get the templates; I don't use it.

You can see at:

http://svn.gnome.org/viewcvs/libgda/trunk/libgda/gda-data-model-hash.h?revision=2593&view=markup

and

http://svn.gnome.org/viewcvs/libgda/trunk/libgda/gda-data-model-hash.c?revision=2863&view=markup


> > I can write you in Chinese, but it's too rude.  >:-()
>
> Well, I know your first language is Español so I was trying to
> help explain in your native tongue to try to get over this
> communication problem that we seem to have.
>
> [snip]
> > I'm trying to help, but that's your opinion, and again WE have a big
> > communication problem.
>
> I realize you're trying to help, but you don't seem to be listening
> to what Chris, David, Josh, and I are trying to tell you.  Every
> once in a while it FEELS like you understand, but then you go off
> and take these huge leaps instead of small steps, or you go off in
> a different direction than what we thought you were going to do.
>
> Again, that's why I was trying to show you, by example, exactly what
> we meant.  Indeed, even *I* got admonished for actually doing a global
> rename of QofEntity, QOF_ENTITY, and qof_entity to QofInstance,
> QOF_INSTANCE, and qof_instance instead of just using #defines.  Still,
> the rest of my branch should show you, by example, what we meant
> (and STILL mean) by "small steps".
>

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.

> As I said earlier, yes, there's much more work to be done:
>  - Properties
>  - Moving the create/destroy code into _init(), _dispose() and _finalize()
>  - Signals
>  - Much more....
>
> And even THESE can be broken down into smaller tasks.  They should
> NOT be done at one time, and after each step the tree should build
> and continue to work (which means it should pass "make check").
>
> [snip]
> > I'll help if you want, if you take this process in your hands, I'll be
> > realy happy, and may I can add, suggest or send patchs.
>
> We would love to have your help.
>
> > I want to see your plan.
>
> My plan:  work in small steps.  I honestly don't have a full plan
> any more detailed that what I've been saying all along:
>
>   * merge QofEntity into QofInstance        <DONE>
>   * get QofInstance to be based on Gobject  <DONE>
>   * move code into init/dispose/finalize    <Each object can be done separately>
>   * add properties                     <Each property can be done separately>
>   * add signals                            <each signal can be done separately>
>   * (more)?
>
> I think we're at the point where each object, or even each feature,
> can be done separately.  The separability is important, because it
> means you can commit a small change that doesn't break the tree.
>
> Granted, some changes will be larger than others (like my QofEntity
> renaming).  Some changes will be much smaller.  But the tree should
> continue to work after very few changes.  Like I said in my original
> announcement, I spent only about 6 hours to get everything using
> GObject in a very rudimentary way.  But it still works, and now we
> can spend more time getting more code migrated over to the "new way".
>

Have you merged with trunk? I want to test a build, see the code and
help when needed.

> > But realy want your comments about my e-mail about to create a library
> > to allow other applications to access the GC's data.
>
> I think such a library is not necessary.  We already HAVE that library.
> It's called "The Engine".  And once the gnucash engine is migrated
> to gobject, well, it'll even be a gobject-based library.  Using the
> engine one CAN access GC's data.  It's even a C library!
>
> > I have some ideas, to add this feature:
> >
> > - Add a GdaDataModel interface to QofCollection object
> > - Try to create a GdaServerProvider for the actual XML file
> > - Create a wrapper library to allow other applications access the XML
> > file (or even the GDA backend) using GDA
>
> Again, I dont think we need any of this, because we already HAVE
> all of this.  (well, except for GDA, but Phil Longstaff is working
> on that in the gda-dev branch).
>

Phil is creating a backend, using QOF as is.

Maybe GnuCash doesn't need GDA at all, except for a backend, but if
you want to access the data in GC you have a library, called actually
Engine, but if we can create an "standard" interface using GDA, this
will allow:

- Get access from Gnumeric, to create powerfull analisys of the data
- Data interchange with other applications
- Import and export data using a CVS file, XML (like QSF does), in a
standard way (some other software are using GDA today)
- Easy data insert/update from other applications, like applets

Of course that the GDA interface *must* use all the GC procedures to
ensure the data integrity and consistency.


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