Skip to main content

[JSR-currency] Re: Important use case regarding rounding

  • From: Sascha Freitag <dunschtig@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-currency] Re: Important use case regarding rounding
  • Date: Tue, 01 Jan 2013 21:36:04 +0100

Hi Anatole/all,

I would not derive from Number. Or what would be the reason for this?I don't see the value of the imposed methods. And they are even not in the intended style of fluent API design, which was once discussed.

Regards Sascha

On 01.01.2013 11:40, Anatole Tresch wrote:
I think this is a good point. Basically we have to check where we best should integrate with other parts of the SE environment. One thing that comes in my mind is 
supporting Formattable. 
Basically also we should discuss, if we want to model Amount by an interface (as it is now) or by by subclassing the abstract java.lang.Number (I assume Number is also part of ME, if not then I dot see this as an option).


2012/12/31 Werner Keil <werner.keil@...>
Anatole/all,

Thanks a lot for the update. Great using Git forks for this
JScience the proposed RI for JSR 275 at the time (and now at least partially implementing Unit-API) had a very similar concept and an Amount type.
Except for the BigDecimal import and reference in the interface (not sure, if it's used or not) it looks good.

Somewhere along the lines of JavaFX Binding:

Given, JavaFX at least on the SE side is on its way to become an integral part of Java, adding something like a MonetaryBinding could even be part of an RI or at least optional extension to the API. Looks like a good idea. 

Werner

On Mon, Dec 31, 2012 at 11:35 PM, Anatole Tresch <atsticks@...> wrote:

Hi Werner /all

Thanks a lot for the update. I think we may consider one or the other JIRA tickets for this. Your java.net account should be in the position to raise one already, please let me know, if there is any problem with JIRA.
I will let you know, if I have some issues with JIRA (I do not expect them, either). I thought it would be better to have a discussion here first, and after we have successfully agreed on the key points to switch over on JIRA. Perhaps this was different as of today, so let me know ;-)
  
Regarding A.6 and B.5 which classes or interfaces do you propose to hold these methods? Some existing in the draft repository or new elements?
Why is the type of internal() simply Object and not a generic value?
Basically the root cause was that I had an interface in mind, where all internals are completely hidden from the clients, including the internal representation. The benefit is that such an interface, e.g. called Amount (see https://github.com/atsticks/javamoney/blob/master/core/src/main/java/javax/money/Amount.java) could enable code to be portable between SE and ME. Whereas when including the type of internal representation into the interface, e.g. as currently modelled in Monetary<T> then a dependency on T is created. When using the Monetary<T>, of course, T internal() would be much more accurate. 
On the other side using Monetary<T> would even allow us to mix different representations in one VM but supporting type safety on compile level. 
Arithmetics should be possible in both variants, as it is possible to evaluate the concrete internal representation during runtime. If the internal type representation do not match, a corresponding valueOf method could be called to gain a representation usable for performing the computation (the resulting type must be the same representation as the instances on which the operation is called).
So basically we have to decide one thing:
  • Do we want to expose the internal representation during compile time? -> Then we should us a generic interface and the internal representation type T should be included where useful. Advantage: We have compile time safety for the internal representation, but for the price of possible incompatibilities when different implementations use different representations of an amount.
  • Or (my preferred solution) do we not expose the internal representation leaving the responsibility completely to the implementation (with some restrictions, such as serialization compatibility and rounding/precision handling). Typically this should be enough for clients. they use the money type (e.g. Amount) similar to a BigDecimal and they basically do not have to care about the details. In that case only runtime compatibility can be ensured, since every reference to the concrete implementation details creates a unwanted dependency. This would make code portable and also different implementations exchangeable.

I would prefer if we found a different method name than of() unless those 2 methods were public static factory methods...?
While a JSR 310 practice unique only to this JSR so far proposes an of() method as factory, any actual factory method in this JSR like valueOf() as in BigDecimal and many others or getInstance() as in the existing Currency class (which of course we'll have to keep backward and API compatible) could be easily mistaken, if this non-static method was simply called of(). 
oh, yes that makes totally sense! I also think "valueOf" is much better than "of", also since the methods are not static ones.


--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Gärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks




--
Anatole Tresch
Java Lead Engineer, JSR Spec Lead
Gärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks@...
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79


-- 

Sascha Freitag v/o Dunschtig
Hofstattstr. 14
9602 Bazenheid

Tel:+41 71 222 2042 
Mobile:+41 79 752 4200


[JSR-currency] Re: Important use case regarding rounding

(continued)

[JSR-currency] Re: Important use case regarding rounding

Anatole Tresch 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Anatole Tresch 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Victor Grazi 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Anatole Tresch 01/02/2013

[JSR-currency] Re: Important use case regarding rounding

Anatole Tresch 01/02/2013

[JSR-currency] Re: Important use case regarding rounding

Sascha Freitag 01/03/2013

[JSR-currency] Re: Important use case regarding rounding

KFSC 52 01/07/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/07/2013

[JSR-currency] Re: Important use case regarding rounding

Sascha Freitag 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/01/2013

[JSR-currency] Re: Important use case regarding rounding

Sascha Freitag 01/03/2013

[JSR-currency] Re: Important use case regarding rounding

Ben Evans 01/03/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/03/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/03/2013

[JSR-currency] Re: Important use case regarding rounding

Ben Evans 01/04/2013

[JSR-currency] Re: Important use case regarding rounding

Werner Keil 01/04/2013

[JSR-currency] Re: Important use case regarding rounding

Anatole Tresch 01/04/2013

[JSR-currency] Re: Important use case regarding rounding

Stephen Colebourne 01/04/2013

[JSR-currency] Re: Important use case regarding rounding

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