CVS update: gnucash/src/engine

[linas@linas.org]

Hi Jim,

Since this is potentially a contentious discussion, read the below with
a grain of salt, and if you don't quite agree, ok; I don't feel like or
want to start an argument.

--linas

It's been rumoured that James LewisMoss said:
> 
> >>>>> On Thu, 15 Feb 2001 11:04:42 -0600 (CST), linas@linas.org said:
> 
>  linas> It's been rumoured that Dave Peticolas said:
>  >>
>  >> Modified Files: kvp_frame.c Log Message: Fix bugs.
> 
>  linas> Um,
> 
>  linas> The routines that I added to the kvp code were added so that a
>  linas> few uneccessary mallocs could be removed.  The changes that
>  linas> you made seem to introduce more than a few mallocs & frees;
>  linas> which obviates the need for the new routines in the first
>  linas> place.  Although the original code fragmented some, the new
>  linas> code fragments worse.  Maybe we should roll back all changes?
> 
> They looked like convenience functions to me.  Three copies of the
> same code with minor differences.  In fact there are two more after
> these three with the same code again.

Right. I noticed that.  I groaned. I thought about macros, and I thought
about the last round of discussions about macros.  And so I figured
that leaving the almost identical copies in place was OK.  Esp since the
bodies were pretty small, pretty tight, it didn't make sense to
introduce convenience functions to reduce code duplication.  Esp. since
the convenience routines only add to the overall complexity, without
adding function.   (I would have concluded differently if the bodies
were larger, but they were small to begin with).

> Also IMO you worry too much about efficiency and reducing mallocs

Its a cardinal sin to not worry always, constantly, and continutally 
about performance.   But don't get me started, I'm not sure I want to go
there today.

> while at the same time making the code more difficult to understand
> and maintain.

Hmmm ... another area where I don't want to tangle in argument.  But in
breif, my new, improved philosphy is: the fewer lines of code, the
easier it is to maintain and understand.   So I go for reducing the
smallest, simplest, most straightforward solution (which by the way,
usually produces the smallest & most highest-performance code).  Which
is why I didn't mind the small amount of code duplication above: it was
small, and simple; and it reduced the loc count in other files by a good
bit.

> Is there a reason you were worried about mallocing here?  Is this code
> actually used by anything?

yes: transaction.c, account.c for account and transaction notes,
tax-related info, reconcile info.   Which the sql backend now saves &
restores.

--linas