the neverending rational vs. integer (they're really the same) saga

[Richard Wackerbarth]

On Wed, 02 Aug 2000, Jason Rennie wrote:

> grib@billgribble.com said:
> >   gnc_numeric gnc_numeric_add(gnc_numeric a, gnc_numeric b,
> >                               gint64 denom, gnc_numeric_round_t how);
>
> rkw@dataplex.net said:
> > The problem is that the calls to do simple things like "add" two
> > numbers all contain elements of the implementation. Therefore each
> > call, in any  routine, might get changed.

This part of my objection is to the fact that his API has a "gint64 denom" in 
it. Why should denom be exposed at all? And it it is, why should the 
implementation retrict it to a gint64? ( I might want to use some BCD 
implementation of integers instead of gint64s. If I were to do so, I 
shouldn't have to go changing things all over the place. The changes should 
be localized to these functions)

> Not in my book it doesn't.  Bill's API is fairly general.  You need
> 'denom' and 'how' in order to do a general add between two quantities of
> possibly different commodities.

But you cannot add "apples and oranges". Therefore there is no need for his 
generalized routine. The simple gnc_amount gnc_amount_add(gnc_amount a, 
gnc_amount b) is adequate in the financial arena.

The addition of dissimilar commodities is accomplished by first converting 
them into a common commodity and then adding those converted values.

>  You could put something on top which
> deals with additions within a commodity ('how' and 'denom' would not
> need to be specified because they are implied).  Why don't you propose
> your own solution instead of constantly criticizing Bill's?

I have. However, you continue to ignore it.

> I think what you want is something that is like Bill's API, but much
> less general.  Bill has infrastructure for all sorts of things that are
> highly unlikely to be used in GNUCash.

Exactly. And they will not be of use in other financial areas either because 
that is not the way that commerce works.