2007/1/11, Chris Shoemaker <[EMAIL PROTECTED]>: > 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) _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
