On 29 January 2013 10:02, Tresch Anatole (KFSC 225)
<anatole.tresch@...> wrote:An object representing money is a value type consisting of a number
> - Currencies are the units, but as we have seen there are multiple units.
> Some may model the same thing in reality, some may model completels
> different things. Also there is no clear and simple relation between
> different types of units/currencies. Even not between the same type of units
> (e.g. real world leagal tendered currencies).
and a unit of currency.
True, but these two are questions of defintion about the currency
> - Additionally currency (also ISO currencies) are defined only within a
> certain time range. For different timestamps you have different currencies
> (also ISO allows to have the same code theoretically being reassigned within
> a certain time period).
> - Additionally ISO Currency codes are not always unique (there is a code
> defined for a African state union, where there are different legal tenders
> mapped to the same ISO code), similarly there are for the same currency (US
> dollars), multiple codes USD, USS, USN.
unit. What makes unit A equal or not equal unit B?
Most people using the JDK are probably absolutely fine with a Currency
value type that is defined solely on an ISO code and ignores the
complexity you've got here. That does not prevent users (or an EE
branch of the spec) from defining a more complex currency (with
history/better IDs) so long as the interface does not prevent it.
An exchange rate object consists of two currency units and a conversion ratio.
> - As a third dimension the exchange rates to be applied also are highly
> complex, they depend
> - on the target timestamp
> - on the concrete contract in place for the use case
> - the location where the exchange transaction should be
The provision of exchange rates is a completely separate problem, and
not something the JDK should be involved in.
|Tresch Anatole (KFSC 225)||01/29/2013|
[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED