[JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
- From: Stephen Colebourne <scolebourne@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: Basic Considerations - YOUR OPINION IS NEEDED
- Date: Tue, 29 Jan 2013 10:47:42 +0000
On 29 January 2013 10:02, Tresch Anatole (KFSC 225)
> - 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).
An object representing money is a value type consisting of a number
and a unit of 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.
True, but these two are questions of defintion about the currency
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.
> - 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
An exchange rate object consists of two currency units and a conversion ratio.
The provision of exchange rates is a completely separate problem, and
not something the JDK should be involved in.