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 14:25:47 +0200

Yes, but can users of CurrencyUnit afford to lose that information.
The getDisplayName() method will return something like "US Dollar".

We know you're a fan of passing the classes directly, but there seem to be quite a few use cases and parts of the API (not just in 354) where you'd pass a reference to an interface (like TemporalUnit, Temporal or CurrencyUnit, MonetaryAmount, etc.) 

So with LocalizableCurrencyUnit, those parts of an application in need of those methods could do:
LocalizableCurrencyUnit locCurrency = Currency.of("USD");
String displayName = locCurrency.getDisplayName();
or any other implementation, especially MoneyCurrency, both implemented this interface, not the base interface.

Now with this lost, all apps or parts of the API referring to the interface need to do:
CurrencyUnit cu = Currency.of("USD");
if (currency instanceof Currency) {
   Currency curr = (Currency)cu;
   String displayName = curr.getDisplayName();
} else if (currency instanceof MoneyCurrency) {
   MoneyCurrency mc = (MoneyCurrency)cu;
   String displayName = mc.getDisplayName();
} else {
   throw new UnknownCurrencyException();
}
   
Referring to implementations directly is not acceptable for the spec API part, even if MoneyCurrency was to remain in such place, it is highly likely that java.util.Currency will implement CurrencyUnit, so having to know exactly which implementations exist and then refer to those providing a get*Name() method would make the API very inconvenient. 

I don't see, why TemporalUnit.getName() returning  a  plural and upper-first camel case, such as 'Days' or 'Minutes'.
won't apply to CurrencyUnit.getName() where exactly the same exists for 'Dollars' or 'Cents'.
(keep in mind, there will be a need of subunits of some form, Simon's thread clearly highlighted this need, even if this was to go into an external API not part of the main Spec)

Unless you have a Locale information, I assume, "Days" or "Minutes" will always remain the same, at least for an enum-backed implementation of TemporalUnit. 

An information that is completely useless if you want to see "Tage" or "Minuten", so unless the getName() method takes Locale.getDefault() into a consideration in its current form it is about as good or bad as the same method would be in 354

Werner

On Wed, Apr 17, 2013 at 2:03 PM, Stephen Colebourne <scolebourne@...> wrote:
There is no real need for a getName() in CurrencyUnit. getName() in 310 provides a human readable version of enum constants for error messages. I don't think the same applies for currency.

Localization should be via getDisplayName().
Identification should be via one of more getters, such as getCurrencyCode().

Stephen



On 17 April 2013 12:47, Werner Keil <werner.keil@...> wrote:
Hi,

I saw, Anatole just removed LocalizableCurrencyUnit. Good stuff, but for the usefulness of CurrencyUnit itself, it must also provide some sort of name.
Whether we rather strictly follow the pattern of JSR 310 TemporalUnit here and call it getName()
(note, the TemporalUnit interface has even a convenience method toString() exposing every concrete class' toString() to the interface as well, normally that and getName() might be the same, but toString() may of course add other information if necessary

or keep only the no-op getDisplayName() from java.util.Currency, I don't really mind either option. Btw. the Chronology base class of 310 did follow a recommendation I made in the 310 tracker http://download.java.net/jdk8/docs/api/java/time/chrono/Chronology.html and renamed a somewhat inconsistent getText(Locale) into getDisplayName(DisplayStyle, Locale). There is no "default" method here, but the "model" or "value" type Chronology contains UI and i18n related methods like getDisplayName, too in 310, so we might as well have either the default one or both in CurrencyUnit. 

Unless a breach with java.util.Currency is preferred, in which case I'd suggest we add getName().

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
 
 
Close
loading
Please Confirm
Close