Otto Stolz wrote:
[...]
> No, I simply wish that they had based their design on correct sup-
> positions. A real-world value (physical, monetary, or whatever) is
> not a mere number, but rather the product of a number and a unit of
> measurement. Changing the unit while keeping the number will affect
> the value no less than changing the number while keeping the unit.
> Example:
> - when you change the width of a diskette from 90 mm to 2286 mm,
> it will no more fit in the drive,
> - likewise, when you change its width from 90 mm to 90",
> it will no more fit in the drive,
> - both 90 mm, and (approximately) 3½" wide diskettes will fit in
> the same drive.
>
> A value in a spreadsheet should never inadvertently change.
>
> Now, Works did exactly that: it multiplied every monetary value
> (in Germany by 1,95583) by replacing its unit with a different
> one, [...]
A perfect explanation of the nature problem, but a poor diagnosis of its
location.
Your description makes clear why, in the retail software industry, we
*never* use some the two elements of "monetary settings" those which define
the actual monetary value of a number.
But you fail to notice that the problem is is not with Works, or with any
other applicative program, but rather with the system-level locale settings
themselves. And, unfortunately, all the operating systems and the
programming languages that I know suffer from this problem.
There are two wrong design assumption in the "monetary settings":
1) The <number of decimals> should not be part of the locale at all. The
fact that US dollars need two decimals does not depend on local convention
of any country, but on the fact that there are coins as small as 1/100 of a
dollar. There should be a locale-independent list of currencies that
specifies this parameter (and other things, perhaps)-
2) The <currency symbol> is to be part of the locale, but each locale should
have an *array* of currency symbols, with an entry for each existing
currency. Having a single <currency symbol> per locale would be like having
one single <month name>!
E.g.: an United States locale could have "$" as the symbol for dollars and
"Mex$" as the symbol for the Mexican peso, while the Mexican locale could
have "$EE.UU." for the former and "$" for the latter. However, US dollars
remain US dollars in both countries, just like "January" and "enero" remain
month #1 in both countries.
So, it is perfectly OK if 1234 dollars show as "$1,234.00" in the USA and as
"1.234,00 $EE.UU." in Mexico, but it is never OK 1234 dollars should become
1234 pesos! (But the opposite is OK, if you do it on my bank account:-)
This implies, as you argued, that the monetary values should contain a
currency Id. Storing money as a simple number is like storing dates with no
year, or integers with no sign.
It also implies that all user interfaces should be changed to allow users to
specify the currecy Id, in case that it is different from the default.
This also makes it desirable that most systems have some form of exchange()
API or service, which is capable of converting monetary amounts from one
currency to another. But this opens the problem that, unlike measurement
units, the value exchange rates fluctuate daily, so there should be some
mechanism to update them.
I don't agree, however, that the actual formatted string should be stored
with the amount. If you change the symbol of the German mark from "DEM" to
"DM", it is OK that amounts previously formatted as "DEM 10,50" become "DM
10,50".
But if you add a *new* currency Id, say <euro>, and set it as the system
default, an existing "DEM 10,50" amount should remain unchanged. The only
effect should be that, if you enter a new amount "10.5" without specifying
the currency, it will be "EUR 10,50".
_ Marco
This archive was generated by hypermail 2.1.2 : Mon Mar 04 2002 - 08:26:46 EST