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

Thanks, I guess a certain level of alignment with 310 EG Members not just Stephen feel was a good idea makes this my first choice, too. 

Even at the risk of having to simply route getDisplayName() of implementing classes like Currency (for MoneyCurrency we don't have to provide this method btw, if we chose to handle i18n elsewhere like "format", getName() seems all that's necessary, while in a possibly implementing java.util.Currency getDisplayName() may simply return what getName() does or vice versa.

the toString() and getName() methods in TemporalUnit are also quite redundant, but if there is a conceivable value in having BOTH, we could think of adding that to CurrencyUnit, too

P.s.: My example was simplified of course, normally you won't create a Currency one line before casting it, but get it from some other part of the application with no clue what implementing class is behind it

Thanks,
Werner

On Wed, Apr 17, 2013 at 2:24 PM, Simon Martinelli <simon.martinelli@...> wrote:
+1 for getName() 

Simon Martinelli
--
Moosentli 7
CH-3235 Erlach

+41 32 544 88 80
simon@...


On Wed, Apr 17, 2013 at 1:47 PM, 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] 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

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