GObject in the Engine example

[Chris Shoemaker]

Just some comments from a brief look...

 1) What's with GdaBinary?

 2) Why don't the Account and Split inherit from the GncObject?
        Consider the ->inst struct members. These should be the parent
GObject.

 3) With inheritance, can't you avoid the mulitple foo_set_qof_book
implementations?

 4) Setting GncObject aside for a moment, don't you think it would be
easier to make these modifications in directly in Account.[ch] and
Split.[ch]?

 5) What if you started at the root of the inheritance tree --
QofEntity?  Couldn't you convert that one struct to a GObject with
almost no impact on anything else?

 -chris

On Wed, Jan 10, 2007 at 06:28:49PM -0600, Daniel Espinosa wrote:
> Attached you'll find a C code example in how I can "hide" QOF from the
> GObject implementation in the GC's engine.
> 
> Please consider the following:
> 
> 1) This is just an example and not all the methods supported for the
> objects had been implemented
> 2) This example just take three objects: the top level in the
> hierarchi (a GncObject), a GncSplit with more detail in methods
> examples and a GncAccount used in GncSplit
> 3) The code try to explain how this objects will interoperate: how a
> virtual functions in GncObject will be implemented by, for example,
> GncSplit
> 4) An interaction between the GncSplit and a poorly implemented GncAccount
> 5) It has a lot of erros and had'nt been tested before, just to show
> an example :-)
> 
> For now, QofBook is required by the *new method in the objects, but
> realy you can miss it and set it after the object has been created for
> exaple (see GncObject), this isn't the final goal just a possibility
> to realy "hide" QOF behind...
> 
> I'm thinking in create a GInterface with methods that must be
> implemented by a object that will be a backend for the interaction of
> the engine with the data, like in QofBackend; in this way the
> GncObject's could call methods without call directly QOF, that will be
> a backend (a Data Provider); this arquitecture could help in implement
> diferent backends but based in a pure GObject framework.
> 
> -- 
> Trabajar, la mejor arma para tu superación
> "de grano en grano, se hace la arena" (R) (entrámite, pero para los
> cuates: LIBRE)


> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel