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@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
