Questions about GObjectification in GnuCash

[Daniel Espinosa]

I think that communication between peaple is dificult, even if they
talk the same language, but I'm trying to describe my ideas to get
feedback as clear as possible, I hope you have time and patience to
hear them.

2007/6/11, Derek Atkins <warlord at mit.edu>:
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
> >> > When will be performed a code clean up? I mean:
> >> > (a) delete the documentation in headers,
> >>
> >> Never.  We WANT the documentation in the headers!  Why would you
> >> want to delete this documentation?
> >>
> >
> > To help others to better understand the code; users must use a API
> > documentation like DevHelp can show, but new developers for QOF can
> > understand so quickly the QOF's internals if there's not TOO many
> > notes and documentation in the code (I can talk about my experience).
>
> The comments are part of doxygen documentation.  The code gets run
> through doxygen every night so you can peruse the documentation:
> http://cvs.gnucash.org/docs/HEAD/   The comments are the documentation,
> so you cannot remove them wholesale.  However, as Josh mentioned,
> reworking the comments to be more succinct would be a good thing.
>

Apears that move to gtk-doc or gnome-doc isn't a consensus right?

> >> > Are there any plan to delete QOF's class registration (to use only GObject)
> >>
> >> I don't think that's possible because we need to be able to
> >> enumerate all the QOF classes.  So we will always need some
> >> QOF class registration.
> >>
> >
> > May be I need to look at the code more deeply to understand, becouse
> > at the moment I've found that this registration is only required for
> > objects' QofParamenter registration and some functions like
> > qof_object_foreach, but some of this features could be replaced by
> > GObject's ones, but this is to know what are YOUR plan.
>
> qof_object_foreach() is used in a number of places (e.g. the
> XML backend code).  We need to maintain that functionality for
> the forseeable future.
>
> > SUGESTION: may be you can use:
> >
> > #define GNC_ID_ACCOUNT g_type_name (GNC_TYPE_ACCOUNT)
>
> Maybe.
>
> >> > What about QofParam, will be replased by GObject properties some time forward?
> >>
> >> Unlikely.  Possible, but unlikely.
> >
> > Could you expand your opinion, isn't clear why is it unlikely?, are
> > there any  QofParam's feature not in GObject's properties?
>
> Yeah, the ability to dynamically add them.  GObject Properties are
> all hard-coded by the object, whereas QofParams allow you to add
> parameters as you add new relationships.
>

Ok, this maybe a feature to keep and extend; will depend on how the
GObjectification goes, but OK.

> >> > Could QofCollections be GObjects?
> >>
> >> I suppose.
> >
> > Well make it happend.
>
> Send me the patch.
>

Working. Just maybe delayed by my work.

> >> > Could QofBook be the operation handler for updates/insert/delete
> >> > objects in its collections or database?
> >>
> >> I'm not sure I understand this question.  What do you mean by
> >> "operation handler"?  We already have this, sort of, through
> >> the Backend APIs, so updates, inserts, deletes, etc. all happen
> >> through the Book using the Backend.
> >
> > If we made QofBook encapsulate all backend operations, maybe it could
> > help some API users to use GC in more easy, and could help the
> > following point...
>
> I don't see any reason to do that.  Users of the GnuCash API have
> all the storage hidden anyways, so I don't see any reason to
> make this change anytime soon.
>

Please comment about the GInterface in the next point, not unswered,
this point is out of context in the main concenr.

> >> > Could QofBook and may be more objects in QOF/GNC, be a GInterface?
> >> > This could allow to create diferent implementations for
> >> > update/insert/delete objects using a different library other than QOF
> >> > (If it's possible, a propose is needed)
> >>
> >> Maybe?  I could certainly see making a QofQueriable interface as
> >> a way to make objects be queriable, and then the QofQuery would
> >> take a QofQueriable instead of a QofInstance.
> >
> > Is possible to create a GInterface called QofQueriable and attach it
> > to QofInstance, then when used in QofQuery you can cast to a
> > QofQueriable object and use its functions interface, don't need to
> > convert QofInstance to GInterface to do this.
>
> Um, yes, I understand that.  Indeed, I said exactly that.  But I
> dont see anything ELSE other than QofQueriable that deserves being
> a GInterface.
>

I know I just pointing that, no more comments, but you don't unswer
the following point in my last e-mail and extern some opinion:

"f we encapsulate all data access operations (insert, update, delete,
query) and backend operations in a GncBook GInterface (consider the
operations in QofInstance object, most of them could be moved to
QofBook or GncBook), it can help to use a diferent "backends" engines.

If possible you can have:

GInterface -> GncBook
With functions to insert/update/delete/query any GObject derived
objects (QofInstances objects)

This interface must be implemented by QofBook, who is using the QOF's
QofBackend infrastructure, to ensure the actual functionality and XML
file format access unmodified .

But is possible to have a GdaBook object implementing GncBook
interface, then you can use GDA's databases backends, and becouse GC's
engine objects use GncBook interface to access the data, GC can use
any QOF (default data access) or GDA transparently, even any other
convenient backend engine"


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