[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:34:52 +0200
Beside, is there a concrete Hangout this afternoon, or some other week?[?]
On Sun, Jul 14, 2013 at 6:03 PM, Werner Keil <werner.keil@...> wrote:
> 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
>> > 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
>> > 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
Description: GIF image