[JSR-354] Re: Getting a name method into CurrencyUnit
- From: Werner Keil <werner.keil@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: Getting a name method into CurrencyUnit
- Date: Wed, 17 Apr 2013 15:07:29 +0200
I don't really see why the "human readable form" in 310 was different, it is a more descriptive (in most cases just Mixed case) version of the unique enum key like "SECONDS". Practically like the UCUM standard has 3 fields for time units it's
minute ||time ||min ||
no Plural btw, meaning 310 violates the UCUM standard, but that just means, other frameworks like Eclipse UOMo have potential to bridge that
So aside from the enum equivalent which would be "MIN" for minutes, there is a context-sensitive code (all lowercase here) and a descriptive name like "minute".
Formatting is clearly molded into the 310 API, as This should be in the plural and upper-first camel case, such as 'Days' or 'Minutes'. as implies, this information can only be used to begin a sentence with, otherwise you'll have to right-case it anyway. So the information in TemporalUnit.getName() and TemporalUnit.toString() are of limited value to phrase it mildly.
An English or other name of a currency may not necessarily be seen as formatting only, but especially in Switzerland, where (http://en.wikipedia.org/wiki/Swiss_franc
) you not only have 4 official names for the currency and its subunits, not to mention all those nicknames like "Stutz" (similar to the English "Quid" or Canadian "Loonie", etc.) only the code could be seen as a unique ID, for ISO maybe next to a numeric Id.
I don't know, if this was appropriate for the core API, but there is no reason that LocalizableCurrencyUnit has to be a sub-interface of the actual CurrencyUnit, a mix of concerns, I always did find a bit suspicious, also from a modularity point of view (i.E. baking Locale into the dependency tree of Core libraries
) but similar to Serializable or Comparable an independent interface like Localizable with methods like getDisplayName() and getDisplayName(Locale) could be provided in format.
A class like java.util.Currency where these 2 concerns are a bit mixed may implement both