GObject in the Engine example

[Daniel Espinosa]

2007/1/11, Chris Shoemaker <c.shoemaker at cox.net>:
> Just some comments from a brief look...
>
>  1) What's with GdaBinary?
>
Its a mistake, I had copy some code to declare a GdaBinary as a
G_TYPE_BOXED derived type, and I forgot to update this reference must
be GncNumeric.

>  2) Why don't the Account and Split inherit from the GncObject?
>         Consider the ->inst struct members. These should be the parent
> GObject.
>
I don't plan to touch QOF, I want to use it as a engine behind the
GncObject implementation.

>  3) With inheritance, can't you avoid the mulitple foo_set_qof_book
> implementations?
>
For this example I saw Split and Account using a diferent function to
set a QofBook, I don't see the internal implementation, then for short
the time for this simple example I had made a separation where they
must implement a virtual function in GncObject to manage how
GncAccount and GncSplit object manages the way or actions to do when a
QofBook is set.

With the actual example, you must use the gnc_object_set_qof_book to
set a QofBook to a GncAccount or GncSplit using polymorphic feature,
you can't use the gnc_split_set_qof_book method becouse it is'nt
public in gnc-split.h file.

This example is to show how I can port the engine to GObject in a
short time, with out modify the actual implementation.

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

There's too much code in that files, I plan to use most of it in the
GObject implementation, if I don't broke the functionality with QOF,
or simple call the existing functions in the GObject's methods, as I
did for this example.

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

I realy don't want to touch QOF, its too much work and time to first
undertand how to reimplement and fit most of the QOF's Object Oriented
functinalities to GObject, as you see in a single hours I had created
an example just using behind the actual objects with out change them.

As I sed in the last email, I want to experiment in GncSplit (for
example) to expose an interface, where a developer must implement in
order to allow this object to work with diferent "engines" like QOF.
If sucessfull QOF will allows to access the data "in his way" with out
modify the actual QOF code (well may be a little); then you can create
others "engines" or backends that implement thouse interfaces  and all
this with out modify the GC's objects.

I'll prepare an other example with this interfaces and how it will be
implemented by the actual QOF based code.
-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)