Skip to main content

[JSR-354] Re: Factoring Out things from MonetaryAmount

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Factoring Out things from MonetaryAmount
  • Date: Fri, 12 Apr 2013 21:30:42 +0200

Yes, I also see the name is not optimal. But I wanted to keep focus on the abstraction first. Basically the "adjusters" in a broad sense are like "calculators" with exact one single amount as direct parameter...


2013/4/12 Werner Keil <werner.keil@...>
Dear Anatole,

Thanks for the update.

If MajorPart or MinorPart are meant to be something like these "SubUnits" or FractionUnits of a MonetaryAmount, then there unlike let's say rounding, I don't fully understand the value and purpose of the adjust() method, which is the only method of MonetaryAdjuster.

Would MajorPart.adjust() return a MonetaryAmount again? Sorry, but that sounds a little odd, if you simply want to get the "Euro" part of "10 Euro, 50 Cents" or "12 Franken, 5 Rappen", just to take 2 simple examples.

Aside from rounding, a bit abstract, but sort of works, there could be more complex adjuster cases like the ones you see in financial time line calculations. 

Adjust the ticket price of a movie from the 1950s compared to one of today's blockbusters, or the famous "Big Mac Index" where you'll see the price of a product like a Big Mac in every country. To make those comparable, prices and local economic conditions also have to be adjusted.

Currency Adjustment Factor is another economic use case for Adjustment: http://www.investopedia.com/terms/c/caf.asp
or Adjustment http://www.investopedia.com/terms/a/adjustment.asp in the context of currencies.

I am not sure, if it's easy to standardize those things, but if we already use something like a MonetaryAdjuster, then users of the API might do things like that, otherwise the term may be not the most optimal one, but for now in the EDR, I'd rather keep that interface and drop Rounding if at least one other implementation exists.

Werner

On Fri, Apr 12, 2013 at 8:40 PM, Anatole Tresch <atsticks@...> wrote:
Dear Colleagues

with the MonetaryAdjuster (reintroduced) we have a flexible thing that allows to some interesting stuff. Beside of chaining using a builder style:

  Money.of(...).plus(10).with(MoneyRounding.of())

it allows also to externalize some of the functionalities that currently are on the MonetaryAmount. I propose to factor out the following functions, into according adjuster implementations:

- min
- max
- minorPart
- majorPart

Additionally some general aspects also could be generalized by defining an alternate interface MonetaryCalculation, which looks like:

  public interface MonetaryCalculation<T> extends Callable<T>{

  public MonetaryCalculation add(MonetaryAmount... amounts);

  public MonetaryCalculation add(Iterable<MonetaryAmount> amounts);

  }

This allows to define according calculations that may use multiple amounts, which would be useful for.

  Min, Max, Total, Average

Basically implementation of such calculations can also be capable of accepting multiple currencies and possibly also defining additional parameters and different result types.
In this context Minimum and Maximum still could also implement MonetaryAdjuster as well, which would enable the following:

  Money m2 = ...;
  Money.of("CHF", 100.25).plus(10).with( Mininum.of(m2)).with(MoneyRounding.of());

Also more complex things could mapped:

  Money.of("CHF", 100.25).with( NetPresentValue.of(0.13).cashIn(50, days1).cashIn(400, days2).cashOut(355, days3)).with(MoneyRounding.of());

Similarly MajorPart, MinorPart can be implemented as MonetaryAdjuster, basically usable as follows:

  Money major = Money.of("CHF", 100.25).with(MajorPart.of());

Similarly MajortPart can provide static methods for accessing long and int, e.g.
  
  public final class MajorPart implements MonetaryAdjuster { // MinorPart similarly

  private MajorPart INSTANCE = new MajorPart();

  private MajorPart() {
  }

  public MajorPart of() {
  return INSTANCE;
  }
  @Override
  public <T extends MonetaryAmount> T adjust(T amount) {
  return toMajorAmount(amount);
  }
  public static <T extends MonetaryAmount> T toMajorAmount(T amount) {
  if (amount == null) {
  throw new IllegalArgumentException("Amount required.");
  }
  BigDecimal number = amount.asType(BigDecimal.class);
  return (T) amount.from(amount.asType(
                             BigDecimal.class).setScale(0,
  RoundingMode.DOWN));
  }

  public static long toMajorLong(MonetaryAmount amount) {
  if(amount==null){
  throw new IllegalArgumentException("Amount required.");
  }
  BigDecimal number = amount.asType(BigDecimal.class);
  return number.setScale(0, RoundingMode.DOWN).longValueExact();
  }

  public static int toMajorInt(MonetaryAmount amount) {
  if(amount==null){
  throw new IllegalArgumentException("Amount required.");
  }
  BigDecimal number = amount.asType(BigDecimal.class);
  return number.setScale(0, RoundingMode.DOWN).intValueExact();
  }
  }

What do you think ? Would be a small change on the core part, but would reduce the size of the amount interface and add a good example of how additionally functionalities/operations can easily be added...
I assume I will also remove the calculation artifacts currently included in the ext module, since I think this concepts here more simpler and also flexible...?

On the other side the current Rounding interface does not provide any additional functionality, so - though "adjuster" is somehow unusual in a financial context, it describes better, for what it is modelled. As a consequence I think, we should really
  • either remove the Rounding interface possibly
  • or adding some functionality to it. But I actually do not see anything to be added here.
I also think that I will add a section targeting the EDR especially to the specification document (or separately), where I try to summarize the most important points, that also created discussions here within the EG. This will help that focus on the topics, where community feedback is crucial. What I see as important are amongst possible other things are the following points:
  • backward compatibility with JDK 7 (6), including usage of new JDK 8 features (Lamba, functional interfaces, 310 types).
  • Scope according to extensions: needed? what kind of?
  • JDK integration (and JSR overall scope)
  • Formatting features
  • Accessors (one shared singleton vs.severals)

Waiting for feedback..., Cheers
Anatole

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

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79





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

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks
Google: atsticks
Phone   +41-44 334 40 87
Mobile  +41-76 344 62 79


[JSR-354] Factoring Out things from MonetaryAmount

Anatole Tresch 04/12/2013

[JSR-354] Re: Factoring Out things from MonetaryAmount

Anatole Tresch 04/12/2013

[JSR-354] Re: Factoring Out things from MonetaryAmount

Werner Keil 04/12/2013

[JSR-354] Re: Factoring Out things from MonetaryAmount

Anatole Tresch 04/12/2013
 
 
Close
loading
Please Confirm
Close