Skip to main content

[JSR-354] Re: Type of MonetaryAmount

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Type of MonetaryAmount
  • Date: Sun, 14 Jul 2013 18:16:05 +0200

Hi,

I rephrased the subject, as it was derived from the other discussion, but
at least the idea of an  AmountType seems not directly related.

Type examples like "MIN_SALARY" or others feel a bit like those attributes
or properties we had in disguise.

javamoney-extras got a few types like CompoundType or MultiValue. And
having "fields" or any sort of user-defined sub-fraction, I am not sure, if
this belongs to a single MonetaryAmount.

Which is why I don't feel comfortable with the 2c which suggests a monetary
amount could be split into fields like "MIN_SALARY", "VAT" or similar.
If on the other hand there was a need for classification somewhat similar
to the ExchangeRate Type, where you may put a series of MonetaryAmount
values into either just a simple collection or something like an "invoice"
and such AmountType allows retrieving and filtering all amounts of type
"VAT" or any other type, I could see value, but I'm not sure, if that'll
breach the boundary between general purpose API and custom application code
in some  cases.

More opinions welcome,

Werner


On Sun, Jul 14, 2013 at 1:25 PM, Anatole Tresch <atsticks@...> wrote:

> 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: Type of MonetaryAmount

Werner Keil 07/14/2013

[JSR-354] Re: Type of MonetaryAmount

Sascha Freitag 07/28/2013
 
 
Close
loading
Please Confirm
Close