Skip to main content

[JSR-354] Re: Mathematical Operations on MonetaryAmount

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Mathematical Operations on MonetaryAmount
  • Date: Sun, 14 Jul 2013 13:25:31 +0200

Hi all

along the discussion on amounts, I would like to add an additional point,
which may be interesting. Often, when we are working with amounts, or
passing them around in our logic, an "amount is not an amount", meaning
that it would be a big advantage, when we would be able to classify amounts
using something like an amount type. Also when working with collections of
amounts according functions (FunctionalInterface)  passed to such
collections can also easily benefit from such a feature.

Basically I would see two main options, how we could model this feature:

1) For both variants we define an additional AmountTypeclass, similar
to ExchangeRate
type.
2a) We extend the current MonetaryAmount with the AmountType. If not set
explcitly, it is set to AmountType.UNDEFINED.
   hereby a result of a monetary operation also automatically
appliesAmountType.UNDEFINEDto its result.
AmountType itself implements MonetaryFunction, so the amounts type can
easily be set with
       MonetaryAmount ma =...; ma.with(AmountType.of("MIN_SALARY"));
2b) The same is basically also possible by adding a
TypedMonetaryAmount wrapper,
which then can be instantiated using an amount: TypedMonetaryAmount ta =
TypedMonetaryAmount.of(ma, "MIN_SALARY");
 But there is one big disadvantage, when using a wrapper:
MonetaryFunction implementations
can not use them, without having to check if it can be cast to
TypedMonetaryAmount .
2c) One additional variant can also be to introduce fields, a bit similar
to what Stephen Colebourne proposed, so we can provide such additional
information in format of a field accessor:
      AmountType type = ma.getField(MonetaryAmount.AmountType);

I personally prefer solution 2a, since its only a minor extension, but
allows the feature without constraint be used by MonetaryFunction
implementations...

So as you see, there are a couple of ideas, but I think we have to further
discuss it. Nevertheless I think that such a type extension would be very
important and also, similar to strongly typed languages, allows to avoid
cumbersome errors, since amounts can be mixed.

Cheers,
Anatole



2013/7/14 tom.huesler@... <tom.huesler@...>

> 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@...> 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@...> 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@...]
>> *Sent:* 13 July 2013 22:29
>> *To:* 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@...> 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****
>>
>>  ****
>>
>>  ****
>>
>>  ****
>>
>> **
>>
>


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

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/*
*Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79*


[JSR-354] Re: Mathematical Operations on MonetaryAmount

(continued)

[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