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: Thu, 18 Apr 2013 15:44:27 +0200

Anatole/all,

Thanks for the reply.

For reasons like that ISO constant that was removed from CurrencyUnit, it would not be good to add
 getIsoName()
to a generic CurrencyUnit. Many currencies and currency schemas, just take Bitcoin do exchange a non localized name. Bitcoin is not as widely standardized yet, but as we see, even ISO (who have a name like Bitcoin flagship Mt.Gox) and Unicode also have slightly different approaches on how this name should be handled or not.

The 2 places where JSR 310 uses getDisplayName() are proprietary to its own API, so unfortunately a getDisplayName(*Style style, Locale locale) would not work even in JDK9 based on the current design of java.time. An interface with a method like getDisplayName(Locale locale) and theoreticaly a Generic wildcard for another form like getDisplayName(S style, Locale locale) of an 
interface Localizable<S> {
}
could have the potential to bridge the gap between at least JSR 354 and 310 if that's desired in Java 9?

TemporalUnit explicitely declared toString(), I am not sure, why that was necessary, but if on the interface level toString() isn't always available anyway and returns just what the concrete class tells it to return, then maybe we should add that to CurrencyUnit, but leave the other *Name() methods so individual implementations, and how they pass them onto toString()?

Werner

On Thu, Apr 18, 2013 at 3:31 PM, Tresch Anatole (KFSC 225) <anatole.tresch@...> wrote:

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

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