[JSR-354] Re: Mathematical Operations on MonetaryAmount
- From: Werner Keil <werner.keil@...>
- To: jcurrency_mail@...
- Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount
- Date: Sun, 14 Jul 2013 18:03:21 +0200
On Sun, Jul 14, 2013 at 4:37 PM, Stephen Colebourne <scolebourne@...>wrote:
> 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
> > correctness.
> There is no good reason to allow multiplication of Money * Money. If
> you did, the answer would in units of Money squared.
That's a good point, and while I can't say, if that was a result for OSGi
Measurement, there are certainly cases for general purpose unit frameworks
like Unit-API, JScience etc. where you'd want to do exactly that.
5m * 2m = 10 m²
but you're right that in the monetary context that seems not useful.
> 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 –
> > 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
> > (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
> > quiet acceptance of a number could lead to the occurrence of a certain
> > of mistake by users of the API.
> > In Joda Money, multiply and divide accept only numbers (BigDecimal,
> > and long). The add & minus methods exist for Money, BigDecimal and
> > 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