Skip to main content

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

  • From: "Tresch Anatole (KFSC 225)" <anatole.tresch@...>
  • To: <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Getting a name method into CurrencyUnit
  • Date: Thu, 18 Apr 2013 15:31:36 +0200

Hi all

 

So now everybody is talking on backwards compatibility. I would focus first the discussion if the name concept is needed or useful:

-          Whereas it is defined for ISO, it is not for non ISO currencies and probably would let people add localization functionality into the name field, what we basically would want to prevent. Display names definitively are related to i18n, and just reintroducing them, only for being backward compatible, means for me to keep things though they are known not to be useful! Also the distinction between a non localizable name and fully i18n support, honestly, for most developers is academic or not understood.

-          Additionally I am thinking about, when I really require a name. For sure it is not identification, for that the codes are there. I only require a name, because I want to show up what currency I have, either on some display or other kind of output. But exact these aspects are the ones i18n is for. So my opinion is, to say it frankly, that getName() is one of the methods that should never have been introduced on util.Currency, or at least it should have been a better name, eg like getIsoName(). Then it would be clear that the name is more related to the underlying ISO standard, than a general concept.

-          Finally, if I want to support developers, e.g. when debugging code, I still can implement the toString method accordingly, which is also the typical outcome you see, when clicking on an item within some introspection view.

 

The only thing I currently would agree, is the introduction of some localization interface, similar to:

 

interface Localizable{

   String getDisplayName(Locale locale);

}

 

But this should be placed best within the JDK, since it is awfully general in nature. Related to that I would definitively not recommend to add the method signature without passing a Locale (using the system default locale), since in almost all multiuser environments, this will lead to problems, when the users for which the names are evaluated have different locales than the current system’s runtime locale.

 

Anatole

 

Anatole Tresch

CREDIT SUISSE AG

Information Technology | Java Core Framework & Support, KSXK 23

Zollstrasse 20/36 | 8070 Zürich | Switzerland

Phone +41 44 334 03 89

anatole.tresch@... | www.credit-suisse.com

 

From: Werner Keil [mailto:werner.keil@...]
Sent: Thursday, April 18, 2013 14:48
To: jcurrency_mail@...
Subject: [JSR-354] Re: Getting a name method into CurrencyUnit

 

Thanks, looks like different organisations handle this differently. And Unicode known to be very language- and locale-aware could pay closer attention to some element's i18n while in other cases (TemporalUnit is said to be fuelled by exactly the same CLDR and it has no getDisplayName() while Chrono or Timezone do in 310) it is left to users and apps themselves.

 

ISO however, does maintain just a single, non-localized name of a currency, see the Swiss(!) local branch of it and a recent change; Oh and last but not least, ISO itself also maintains an English currency name.

 

Here is its complete set of currencies in Excel or XML form

 

While Entity is a pointer to either Locale or Region, the following attributes match those in CurrencyUnit, except the missing name:

Currency

Alphabetic Code

Numeric Code

Minor unit

 

Minor unit is the equivalent of defaultFractionDigits, the other 2 are *Code() methods.

To honor those sources maybe we should also keep a "name" or "description" field, otherwise it leads to fragmentation among implementations.

 

Whether or not CurrencyUnit should follow the pattern of TemporalUnit and simply store the ISO or other data source's (usually English) descriptive name and call it getName() or similar, or go along the lines of JSR 310 Chrono/Timezone with a getDisplayName() method, remains to be seen, but for backward compatibility with java.util.Currency if the getDisplayName() version was preferred, I'd also keep the no-op getDisplayName() eventually leaving it to an implementation, if it uses the name as provided by the source/stream or according to Locale.getDefault().

 

Regards,

Werner



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

(continued)

[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

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

Chris Pheby 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

Tresch Anatole (KFSC 225) 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/17/2013

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

Werner Keil 04/17/2013
 
 
Close
loading
Please Confirm
Close