Skip to main content

[JSR-354] Re: Ballot - please reply soon!

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Ballot - please reply soon!
  • Date: Tue, 9 Apr 2013 14:44:11 +0200

Hi,

On Tue, Apr 9, 2013 at 2:22 PM, Stephen Colebourne <scolebourne@...> wrote:
On 8 April 2013 22:35, Anatole Tresch <atsticks@...> wrote:
> Core (answer with Y or N, my opinions are inline):
> 1) Remove LocalizableCurrencyUnit, LocalizableAmount?
Y

> 2) Use 310 names for methods on MonetaryAmount:
Y
http://blog.joda.org/2006/05/immutable-pojos-improving-on_6406.html (from 2006)
http://blog.joda.org/2011/08/common-java-method-names.html

Given the method names, JSR 275 / JScience used roughly around the same time (between 2005 and 2008)
those are closer to Joda/310, except that an EC lead by people like Josh Bloch then forced us to change the method signature to match BD. Given 310 has not been changed like that after its merge with the JDK, method names like those don't seem a big issue and would get the JSR back to where 275 or Joda once started
 
> 3) Should we replace the methods asType, intValue, doubleValue etc. on
> MonetaryAmount, with BigDecimal getBigDecimal()?
In the context of what the interface is currently trying to be,
getAmountAsBigDecimal() is better. (I prefer a different kind of
interface though)
The word Amount in the method seems redundant, if you had it, getAsBigDecimal() at most, but I mentioned, having it in the concrete value class looks unproblematic, putting it into the interface will force EVERY implementing class, even those who want to abandon BD for reasons several EG members expressed to use it, otherwise they won't be Spec-compliant


> 4) Should we support Number as input type on algorithmic operation on
> MonetaryAmount also?
N
Its entirely unsuited to that task, as you can't extract data from it reliably

Thanks to inheritance, any concrete subclass based on either BigDecimal, Long or whatever can safely override that in the class. add(Number) or plus(Number) turns into add(BigDecimal) or plus(BigDecimal) hence the whole precision thing in that particular class is only as good or bad as the implementing class itself, there is no loss of reliability. You can also pass a 310 Duration to code that requires it as TemporalAmount and not loose anything
 
> 5) Should we rename the Rounding interface to MonetaryAdjuster?
N
I was proposing Rouding is a special case of adjustment, so such a
class would still exist.

> 6) Should we CHange Rounding:  public MonetaryAmount round(MOnetaryAmount
> amount); would be changed to public <T extends MonetaryAmount> T round(T
> amount);:
Y

> 8) Should we introduce an additional RoundingType, to distinguish the usage
> such as cash, online, card?
N

Stephen


Werner


[JSR-354] Ballot - please reply soon!

Anatole Tresch 04/08/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/08/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Sascha Freitag 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

Stephen Colebourne 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Tresch Anatole (KFSC 225) 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/09/2013

[JSR-354] Re: Ballot - please reply soon!

KFSC 52 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

KFSC 52 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

Werner Keil 04/16/2013

[JSR-354] Re: Ballot - please reply soon!

Cullen Robert J. (KGOU 34) 04/16/2013
 
 
Close
loading
Please Confirm
Close