Hi, I'll try to keep my comments high level as best as possible..
Neil Williams <[EMAIL PROTECTED]> writes: [snip] > http://www.codehelp.co.uk/code/index.html I haven't looked here, yet. I presume there's more info at this website, but frankly I've been dealing with a broken machine all week. > The manpages for g_merge, qofbook and gncinvoice are more for my own reference > than anything else, although I have put some comments in some files. g_merge sounds like a glib function. This should either be 'qof_merge' or 'gnc_merge', depending on where it lives and how general it is. > // The Primitives > #define GMCHAR 1 > #define GMINT 2 > #define GMFLOAT 3 > #define GMDOUBLE 4 > // First level compound / customised > #define GMSTRING 10 // char* > #define GMGBOOLEAN 11 > #define GMGINT 12 > #define GMGINT16 13 > #define GMGINT64 14 UGG! Why are you doing this? The objects are all pluggable _for a reason_. PLEASE PLEASE PLEASE use the plug-in modules instead of a bunch of #defines. If you have a #define it makes it VERY hard for a plug-in module to insert a new data type. > // Second level compound - objects that can still be resolved to a single > primitive > #define GMGNC_QUOTE_SOURCE 100 > .... > // Third level - objects that contain more than one primitive. > #define GMGNC_COMMODITY 1000 Again, I'm not sure you really need to do this. Can't you just add to the object definitions? > Compound objects are then further defined in terms of their component > primitives. > Note that gnc_commodity is not complete in this example - it has been > shortened to allow easier testing. The create_rule adds the details of each > field in the compound object to the rule set for that object. > > #define GMGNC_COMMODITY_FIELDS(x) { \ > create_rule(x, "fullname", GMSTRING); \ > create_rule(x, "namespace", GMSTRING); \ > create_rule(x, "mnemonic", GMSTRING); \ > create_rule(x, "printname", GMSTRING); \ > create_rule(x, "exchange_code", GMSTRING); \ > create_rule(x, "fraction", GMINT); \ > create_rule(x, "unique_name", GMSTRING); \ > create_rule(x, "mark", GMGINT16); \ > create_rule(x, "quote_flag", GMGBOOLEAN); \ > create_rule(x, "quote_source", GMGNC_QUOTE_SOURCE); } > > So far, a routine is working to assemble these rule sets into a workable > structure. This is looking AWFULLY similar to the qof-object definitions. Frankly, the _LAST_ thing we need is _yet another_ place where an object needs to be defined. Can we try to centralize this as much as possible? We already need to re-define objects multiple times (C struct, QofObject, XML Schema, and SQL Schema).. I know Linas is trying to keep this down to two (C struct and QofObject) and then derive the XML/SQL Schema from the QofObject.. I'd personally rather continue along that path and extend QofObject to meet your needs: QofMergeResult qof_object_merge_compare(QofInstance*, QofInstance*); > Next stage is to get the data into the same structures as the rules, > then the comparison functions can start. I hope the comparison functions are based in the core objects??? -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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
