Skip to main content

[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  min MIN  no60 s 
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

Cheers,
Werner



[JSR-354] Getting a name method into CurrencyUnit

Werner Keil 04/17/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Stephen Colebourne 04/17/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/17/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Anatole Tresch 04/17/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/17/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Simon Martinelli 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Simon Martinelli 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Anatole Tresch 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Werner Keil 04/18/2013

[JSR-354] Re: Getting a name method into CurrencyUnit

Sascha Freitag 04/20/2013
 
 
Close
loading
Please Confirm
Close