C++ and derived classes issue
geert.gnucash at kobaltwit.be
Sat Feb 13 12:56:02 EST 2016
(Nope, part is still cut off... I'll send that part separately now, hopefully that works.)
Missing part from previous mail:
5. You propose to make all the possible import items properties of the Transaction GObject. I'm
not really in favor of that as several of these import items are actually properties of splits to
create. The name "Transaction" is used fairly liberally in the importer to mean a Transaction (in
the engine sense of the word) together with its Splits. I don't think it's appropriate to add all of
those into the Transaction engine object. On the other hand, having both a set_trans_property
and a set_split_property again breaks the encapsulation. The calling object needs to know
when to use which.
6. And it gets worse. There is the 'num' property of transactions. Depending on a user
preference, this can also be stored in a split instead. So if the import data has a 'num' item, I
can't just call
g_object_set (trans, "num", &val) on it, because it may have to be set for a split instead.
7. And lastly there's no direct mapping between the "Debit", "Credit" and "Balance" import
types on the one hand and the split amount/value on the other.
If the import data has both a Debit and a Credit column the split's amount should be Debit-
Credit. If it has a Balance column instead, a whole different calculation will be done later on in
the generic importer code.
I'm beginning to wonder whether using a separate class to characterize just one property is
actually the right approach...
More information about the gnucash-devel