Skip to main content

[JSR-354] Re: Mathematical Operations on MonetaryAmount

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount
  • Date: Sun, 14 Jul 2013 15:37:50 +0100

On 14 July 2013 13:30, Chris Pheby <chris@...> wrote:
> 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.

There is no good reason to allow multiplication of Money * Money. If
you did, the answer would in units of Money squared.

There is no good reason to have the multiply/divide method take a
Number however. You cannot get any information out of a Number object
without instanceof checks, which defeats the purpose of using Number
in the first place. There should be separate methods for each relevant
type, such as BigDecimal, long and double.


> 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.

With Plus/Minus, (Money + Money) is the correct way to work, but
(Money + number) is sufficiently clear that it is useful in some
contexts. It could be argued that it is a luxury with the potential to
confuse.

Stephen


[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