Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls: > > On Apr 28, 2020, at 7:27 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> > > wrote: > > > > However numbers are not just meant for displaying, one needs to do > > calculations on them as well. And at that point signs will matter. > > Whether a certain number increase or decrease your balance is a matter of > > sign. > > Maybe we should change that: Instead of using operator+() and operator-() we > could have a balance class with functions credit() and debit(). It would > have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe > follow the European model and just do ActiveBalance and PassiveBalance) > whose overrides of credit() and debit() would do The Right Thing. > > Regards, > John Ralls
That's certainly something to consider for future development. It just encapsulates the math a bit further. Nice thing there is that we only have to think about it once, namely the moment we set up this class hierarchy. Or not... data still has to enter gnucash and the outside world rarely speaks in debits or credits. The receipt I get from my last restaurant visit just mentions an amount to pay, the csv I get from my bank talks of deposit and withdrawal,... So while good for internal representation I think gnucash will always have to provide the convenience terms for data entry (or display) in addition to the more formal terms. Regards, Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
