[JSR-354] Re: Denominations and Fractions
- From: Werner Keil <werner.keil@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: Denominations and Fractions
- Date: Tue, 16 Apr 2013 18:53:27 +0200
Here's a thought for 2 possible scenarios where subunits of a currency unit could be placed by the API.
- Follow the concept of JSR 310 TemporalUnit and replace the getCurrency() method in the MonetaryAmount interface with something like getCurrencies() or getUnits() see below:
While a list instead of a single value might be a little odd to some, Java 5 and above offer decent "for each" handling where even those lists with only a single entry are not a big problem.
Unlike the current approach of MajorPart and MinorPart if we went down this road, a similar get(CurrencyUnit) like
also seems mandatory, but it would at least return a MonetaryAmount again, just like the current Major and MinorPart classes do. preserving the information, otherwise only a numeric representatation (as which class/type?) similar to the simple long value for TemporalAmount could be returned by such MonetaryAmount value.
- Try to tackle this on the CurrencyUnit level, by taking the spirit of the already existing
public int getDefaultFractionDigits();
method and adding a List like
public List<CurrencyUnit> getFractionUnits();
or similar such as getFractionCurrencies, etc.
The structure of MonetaryAmount would remain as is, the MajorPart or MinorPart operators may have to be revisited to some extent, e.g. allowing a CurrencyUnit parameter to extract a sub-amount there in some form.
A simple flag like
public boolean isFraction();
on a CurrencyUnit may help to tell the whole currency apart in either case. And unless "chained fractions" (e.g. Cents into Millis for US$) were allowed, a currency unit with isFraction() true would normally have no further fractions, so the list may either be null or an empty list.
In addition to that, the getDefaultFractionDigits() method on the parent/whole currency may either be inherited by all fractions, or set to a different value, that's a detail, and I'm sure, a reasonable value could be found. Something like
public int getFractionDigits();
on each fraction currency (the parent can only tell the default, thus another good way to tell which of the fractions if multiple exist are the Default) sounds useful.
Should those be too cluttering to the actual CurrencyUnit, then unlike LocalizableCurrencyUnit (one more reason we might want to remove/merge that) a sub-interface FractionCurrencyUnit or CurrencySubUnit may also work leaving a
public List<FractionCurrencyUnit> getFractionUnits();
on the actual CurrencyUnit while keeping those other methods for the specialized sub-interface. Hence the isFraction() flag would be unnecesssary, the type of the object tells which one.
Any thoughts, preferences.
1., 2. or a proposal of your own how this could best be addressed?