Questions about GObjectification in GnuCash

[Daniel Espinosa]

2007/6/1, Derek Atkins <warlord at mit.edu>:
> Hi,
>
> "Daniel Espinosa" <esodan at gmail.com> writes:
>
> > Does any one know why QofInstance's functions use gpointer instead of
> > QofInstance* ?
>
> Um, probably because they haven't been fixed, yet?  Yes, they
> should use QofInstance.
>
> > Does any one know why when you change QofInstance object's Book, just
> > change the pointer? May be you need: (a) remove from the actual book's
> > collection (b) add to the new book's collection (c) change the pointer
> > to the new book (This process is performed in QofInstance set Book
> > property at gobject-engine-dev branch...)
>
> Honestly I don't know.  I suspect it might be a bug, but this
> functionality isn't used anywhere so it's not being hit.  I think
> you're right that this should probably change.
>
> > 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).

> > (b) use some convention about object's function's name
>
> We already have a convention about object function names.  It
> may not be the convention that you want or that glib uses
> or that someone might use when writing new code, but it's
> still a convention.  So, I don't expect this to change anytime
> soon, either.
>

Again, if the future this change will help the API users.

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

> > What about string based type system?
>
> EVENTUALLY we might want to change this, but again this is
> something that doesn't have to change right away.  Right now
> there's a duplication here, there's the string type name and
> the GObject type name/number.  We would need to change the way
> we define types in QOF before we could completely get rid of
> the string types.
>
SUGESTION: may be you can use:

#define GNC_ID_ACCOUNT g_type_name (GNC_TYPE_ACCOUNT)

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

> > Could QofCollections be GObjects?
>
> I suppose.
>

Well make it happend.


> > Could QofBook directy use a Database engine instead of in-memory
> > collections? I mean: use database's tables, instead to have a
> > in-memory copy of objects in the hashtable QofCollections
>
> No.  At least not in the short or medium term, and it's not really
> something that's being considered for longer term, but who knows
> how we'll feel in another five to ten years?
>
> > 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...

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

>But I don't see
> any reason to convert, say, an Account into a GInterface.  I don't
> see a reason to make the Book an interface, either.

If 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

>Honestly,
> the only thing I can think of that might want to be an interface
> is "Queriable".   But that's still a medium-term project, not a
> near-term project.

Yes not for 2.2 release.

>
> I hope this helps,
>

Of course yes; but I would like to see opinions from other developers.


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