Proposal for modifying gnucash to use exact quantities
Terry
tboldt@attglobal.net
Sat, 29 Jul 2000 13:35:55 -0400
On Fri, 28 Jul 2000, you wrote:
> > I haven't seen a
> > similar single discription and corresponding implementation on your
> > proposal.
>
> I haven't made it in that form because it is too trivial.
That should make it easier to put down so that others can review it, comment on
it, improve on it, etc. With no proposal, even a trivial one, all you are doing
is arguing over the number of angels on a pinhead. Also, you need a supporting
implementation that will put your ideas into something that works or doesn't
work. Bill may be right or wrong, but at least we'll find out by trying to use
his implementation. You can argue that you are right, but without actually
trying your code, nobody will ever really know for sure
> Bill has defined a complex infrastructure to attack a simple problem.
Maybe, but at least he has defined it and implemented it in a fashion that is
ready for integration and use and thus testing by real people in real
situations.
>
> At the level of Bill's proposal, I have:
>
> typedef gnc_amount; ANY representation of integers what satisfies the dynamic
> range required for a particular use. Note that I, personally, will never
..
..
..
..
>
> obfuscate the ordinary case with the extra parameters necessary to fold all
> of these cases into one common function call.
Okay you have made a start. Now put all of this into a "trivial" document that
defines things without the handwaving and provide the "trivial" implementation
that can be integrated into gnucash (probably by yourself, you have the source
code I assume, yes/no?)
>
> The interesting functions are those which actually handle the functionality
> of transactions such as displaying values.
>
> I would handle this by a pointer to a structure which carries the information
> about the preferences for handling particular kinds of amounts.
> These are similar to the gnc_currency items that Bill has proposed.
>
> As I have said before, we don't need MATH routines. We need to define
> FINANCIAL routines. Until those routines are defined, it is premature to
> attempt to define the precise math routines that are appropriate.
Then provide the routines that are needed. YOU define them EXACTLY, without any
ambiguity, such that they can be implemented. You have argued and argued, now
simply go DO IT.
>
> I am still waiting for Bill, or someone else, to show how his implementation
> will simplify the actual higher level routines that we need to implement.
And that seems to be the crux of this matter, you want to argue everybody into
submission. You cannot do it. The reason the people are on this mailing list is
because they are independent. You are waiting and arguing and NOT DOING.
>
> I view Bill's implementation like Southwest Parkway, a multi-million dollar
> roadway leading nowhere. It was a fine roadway, but did not serve a real
> purpose because it addressed a non-existant need. It cost additional millions
> to convert it into something useful.
>
> PLEASE, plan before you implement.
Agreed - Implementting without planning is a disaster.
But
Planning without implementation is just as great a disaster.
As I keep saying, JUST GO DO IT.
You don't need anyone's permission. Once you have an exact specification and
implementation thereof, it can be tested in gnucash, just like Bill's.