Questions about GObjectification in GnuCash

[Derek Atkins]

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?

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

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

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

> What about QofParam, will be replased by GObject properties some time forward?

Unlikely.  Possible, but unlikely.

> Could QofCollections be GObjects?

I suppose.

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

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

I hope this helps,

-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