Skip to main content

[JSR-354] Re: Mathematical Operations on MonetaryAmount

  • From: Chris Pheby <chris@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount
  • Date: Sun, 14 Jul 2013 12:30:31 +0000
  • Accept-language: en-GB, en-US

Werner, Tom, Anatole,

For multiplication / division I still fail to see a case where it makes sense 
to multiply one monetary value by another. Including these methods does not 
even add convenience since to invoke you would have to convert a number into 
a MonetaryAmount before you invoke them. My view is these methods should be 
removed and the API should definitely err on the side on correctness.

For add, subtract there is a case for the convenience methods - implicitly 
you are working with money in this case. As you mention this is analogous to 
'<>' where the type can be inferred from the context.

There is one case that definitely needs more consideration which is the case 
of integer number types - i.e. short, int and long. In these cases there is 
ambiguity over whether the value represents major or minor amount (dollars or 
cents). To me this is especially of concern since it is quite common for the 
minor value to be used as a representation. I think that the quiet acceptance 
of a number could lead to the occurrence of a certain kind of mistake by 
users of the API.

In Joda Money, multiply and divide accept only numbers (BigDecimal, double 
and long). The add & minus methods exist for Money, BigDecimal and double. 
The methods that accept long are explicit in terms of accepting major or 
minor values (via the method name) so it is a deliberate decision whether to 
subtract (e.g) Dollars or cents. I think this is an improvement over the 
implicit conversion because it forces the user of the API to determine 
explicitly what the integral value represents.

Regards Chris

From: Werner Keil [mailto:werner.keil@...]
Sent: 14 July 2013 18:18
To: jcurrency_mail@...
Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount

Tom/all,

Since it's been around for quite a while (though in OSGi 5 it seems, this API 
is dropped[cid:image001.gif@01CE80CC.4F47EAC0]) OSGi Measurement could be 
seen as a very early example for similar calculations, though it deals with 
more general measurements than just monetary amounts. Beside every operation 
using just a number argument it offers both the measurement itself and a 
tupel of number and unit (which clearly seems a bit redundant, that is what 
the measurement/amount also contains)

JScience and its monetary package has even more such operations, including 
those with several primitive types. Not to mention JodaMoney offering a 
variety of all sorts of convenience methods. I certainly wouldn't say get as 
far as that (we managed to simplify the API so far compared to some initial 
inspirations from its earlier versions) but having one general purpose 
convenience method probably helps especially when you deal with data from 
other libraries.

It may only save something like
MonetaryAmount money2 = money1.add(Money.of(money1.getCurrency(), 10));
compared to
MonetaryAmount money2 = money1.add(10);

Taking auto-boxing into consideration, you may want to use a number type of 
your choice, but this code should also 
work[cid:image002.gif@01CE80CC.4F47EAC0]

The multiply and divide operations could probably do more easily without the 
amount, though it may not hurt to have them, Especially since the spec refers 
to MonetaryAmount being modeled somewhat after BigDecimal. And for all these 
operations it is exactly how BigDecimal does it, so we may want to keep these 
analogies, where it makes sense.

Werner

On Sun, Jul 14, 2013 at 12:24 AM, tom.huesler@...<mailto:tom.huesler@...> 
<tom.huesler@...<mailto:tom.huesler@...>> wrote:
I agree with chris that on the multiplications its confusing... You dont 
multiply a Monetary value with another but with a natural 
number....semantically it doesn't seem correct to multiply / divide two 
monetary values.

So in my opinion it should be
Multiply(number)
.... The other signature i would likely drop.

Also I'am not sure if the add(number) really makes sense from a semantical 
point...

On 13.07.2013, at 16:57, Werner Keil 
<werner.keil@...<mailto:werner.keil@...>> wrote:
GBP 5 * USD 5 would currently throw a CurrencyMismatchException. And so did 
something like
GBP 5 + EUR 5, etc.

Explicit conversion of one currency before you perform those operations is 
required and unless very specific implementations doing that under the hood 
were written (unlikely that makes sense for RI, at least there are always 
different conversion rates and fees for such conversions)

EUR 5 + 5 can be seen more or less like a convenience method. Take some of 
the "Diamond" improvements to Java 7.
Previously you had to declare a generic type twice, now Java will recognize 
and use the correct type for you.
Given the most common cases will use the same currency and calculations with 
different currencies at least by the RI would normally throw an exception, I 
would not say the MonetaryAmount + MonetaryAmount version should be dropped, 
but the "convenience" or "diamond like" version that assumes the only valid 
currency seems quite appropriate, too.

Werner
On Sat, Jul 13, 2013 at 4:34 PM, Chris Pheby <chris@...<mailto:chris@...>> 
wrote:
My question was:

GBP5 *  5  = GBP 25 is clear enough

But not sure about

GBP 5 * GBP 5
or even
GBP 5 * USD 5

In what situation would you perform these multiplications?

Similarly

EUR 5 + EUR 5 seems clear
But
EUR5 + 5 is less clear

Regards Chris

From: Werner Keil [mailto:werner.keil@...<mailto:werner.keil@...>]
Sent: 13 July 2013 22:29
To: jcurrency_mail@...<mailto:jcurrency_mail@...>
Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount

I remember the latter method was to add a numeric amount of the same 
currency. We do have a restriction or guidance, that the currencies of both 
arguments should be the same, otherwise one would never know, which exchange 
rate to explicitely use and where to take it from<image001.gif>

So I'd say it makes sense in both cases. For multiplication it certainly does 
even more, are we missing a numeric only argument there?

Regards,
Werner
On Sat, Jul 13, 2013 at 4:15 PM, Chris Pheby <chris@...<mailto:chris@...>> 
wrote:
On MonetaryAmount, most of the mathematical operations are overloaded for 
both MonetaryAmount and Number as parameters. I am not sure this should be 
the case.

For example, add and subtract:

    public Money add(MonetaryAmount amount);
    public Money add(Number amount);

Adding two MonetaryAccounts makes perfect sense, but adding a number to a 
monetary amt - less clear. Why not just convert the number to a 
MonetaryAmount explicitly.

For the multiply, divide... and remainder methods, the opposite may be true. 
In this case, it is unclear what the meaning of using a MonetaryAmount as an 
operand is.

Regards Chris




GIF image

GIF image



[JSR-354] Mathematical Operations on MonetaryAmount

Chris Pheby 07/13/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/13/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Chris Pheby 07/13/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/13/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

tom.huesler@... 07/13/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Chris Pheby 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Stephen Colebourne 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/16/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Sascha Freitag 07/28/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Werner Keil 07/28/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Anatole Tresch 07/14/2013

[JSR-354] Re: Mathematical Operations on MonetaryAmount

Stephen Colebourne 07/14/2013
 
 
Close
loading
Please Confirm
Close