On Fri, 30 Jun 2000 07:13:03 MST, the world broke into rejoicing as
Randolph Fritz <[EMAIL PROTECTED]> said:
> On Fri, Jun 30, 2000 at 01:19:03PM +0200, Ralf Gorholt wrote:
> >
> > perhaps I understand something wrong but I think one of the purposes
> > of operator overloading in C++ is to be able to write something like
> > "x = y + z" instead of "gnc_money_plus(x, y, z)", even if the "+"
> > operator does complex, not necessarily arithmetic operations instead
> > of just a simple addition. At least I use it that way...
>
> Can't scheme be made to do that? I mean, it knows enough to overload
> arithmetic operators for integer and floating-point already. Wouldn't
> this just be another numeric type?
Come on, people. The issue is _not_ what "object system" is being
used, or what language is being used, but rather _what the numeric
representation should be_.
If I see another suggestion that GnuCash be rewritten in C++ because
C++ offers some aspects of operator overloading, I'm going to scream.
The suggestions, to that end, have really amounted to:
"Why don't we adopt C++? It has some cool object stuff, and if
we adopted that, I'm sure someone could come up with a data
representation that would be suitable."
To put the issue off to "Well, if we adopt C++, someone else will think
of something..." is an aggravating waste of bandwidth.
C and C++ have the _same_ basic sets of basic data types; any money
representation that is expressible in C++ is equally expressible in C.
Moving to C++ does not magically add in a horde of new numeric data types.
If you have ideas on a _data type_, then by all means speak up.
Suggesting mere syntactic sugar misses the point of the exercise, which
is a _DATA TYPE_.
Options that leap to mind involve the following:
-> The numeric amount should involve a "big integer," and a radix.
Thus,
struct {
gint64 amount;
gint8 radix;
} basic_money;
-> There should be some indication of the currency that is involved.
Thus...
struct {
char curr[3];
gint64 amount;
gint8 radix;
} more_complex_money;
There is a bit of a problem with this; there is the redundancy that
the radix is determined by the currency, so that we would need _two_
structures that "cross link":
struct {
char curr[3];
gint8 radix;
} curr_info;
struct {
char curr[3];
gint64 amount;
} linked_complex_money;
Further than that, the way the currency works _may_ be date-dependant.
For instance, if Mexico does a redenomination of their currency due to
rampant inflation, we might need to have "old pesos" and "new pesos."
In effect, the amount depends on the date on which it occurs. Mind
you, that starts making things cross-link _even more_, which seems
to me to be a bad thing.
Frankly, I think the best option is:
struct {
char curr[3];
gint64 amount;
gint8 radix;
} more_complex_money;
as this combines the data that we want to know about, and diminishes
the need to look up more.
By the way, I am willing to assume decimal amounts, as even the
stock markets are "decimalizing." If that be not the case, then
my "favorite" representation is:
struct {
char curr[3];
gint64 numerator;
gint64 denominator;
} complex_money;
The other _major_ alternative would be to look to the OMG's
FBO:Curr class, which uses the IDL "fixed" type. fixed maps, in
C, to:
struct {
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[ceiling((intpart + decimals)/2)];
} CORBA_fixed_whatever;
If others have suggestions for _data structures_, feel free to
suggest reasons why your _data structure_ is preferable to one
of the above.
Please _don't_ waste bandwidth arguing over the merits of different
forms of object overloading, unless you figure that will contribute
_significantly_ to determining an appropriate _data structure_.
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/>
Random hacker: Oz needs to be booted.
RMS: Ok, I'll break open a window.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
