C++ and derived classes issue

[Geert Janssens]

(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...

Geert