9 ms·

The currency exchange support is way simpler than this. The library only provides a method that will calculate the monetary amount given another Money object as

The currency exchange support is way simpler than this. The library only provides a method that will calculate the monetary amount given another Money object as the rate: val amount = 1 money "USD" // USD 1.00 val rate = 5.4905 money "BRL" // BRL 5.4905 amount exchange rate // BRL 5.49 It's up to implementers to hook up in other datasets and to consume the rates. Exchange rates datasets differ from country to country and some foreign exchange companies offer short-term contracts to hold a transaction at a given rate (sort of "guaranteed rate/price"). I don't see myself supporting this use case. Nevertheless, Java Money (Moneta) has this feature. Never used it so, I don't know how it works.

proper_elb 2y ago
Thank you for your insights! I think it makes sense that this feature would not be planned in your library - as I understand, its goal is to support developers to write better money-related logic, which is sometimes related but different from simulating as accurately as possible. I just noticed a potential misuse of your API: Transitve relationships: "A" = 2.0000 "B", and "B" = 3.0000 "C", then implicitely, "A" = 6.0000 "C". Can the user now define "A" = 7.0000 "C"? That would be wrong - but not trivial to prevent, and practically speaking, it is okay I think. Thank you for your time and for this exchange, wish you good success and fun with kotlin money! :)
- alluringorange 2y ago
  Exchange rates are often not perfectly aligned, even if for a short periods of time. This is where arbitrage comes into play and levels the market. With that we can go back to the example: "A" = 2.0000 "B" "B" = 3.0000 "C" -> "A" = 6.0000 "C" "A" = 7.0000 "C" If you notice this happening in the real world, you have the opportunity to: 1. buy 7 "C" with 1 "A" 2. buy 2 "B" with 6 "C" 3. buy 1 "A" with 2 "B" 4. keep 1 "A" profit But it's rarely that simple and it often involves 3 or more currencies

proper_elb 2y ago

Thank you for your insights! I think it makes sense that this feature would not be planned in your library - as I understand, its goal is to support developers to write better money-related logic, which is sometimes related but different from simulating as accurately as possible. I just noticed a potential misuse of your API: Transitve relationships: "A" = 2.0000 "B", and "B" = 3.0000 "C", then implicitely, "A" = 6.0000 "C". Can the user now define "A" = 7.0000 "C"? That would be wrong - but not trivial to prevent, and practically speaking, it is okay I think. Thank you for your time and for this exchange, wish you good success and fun with kotlin money! :)

alluringorange 2y ago
Exchange rates are often not perfectly aligned, even if for a short periods of time. This is where arbitrage comes into play and levels the market. With that we can go back to the example: "A" = 2.0000 "B" "B" = 3.0000 "C" -> "A" = 6.0000 "C" "A" = 7.0000 "C" If you notice this happening in the real world, you have the opportunity to: 1. buy 7 "C" with 1 "A" 2. buy 2 "B" with 6 "C" 3. buy 1 "A" with 2 "B" 4. keep 1 "A" profit But it's rarely that simple and it often involves 3 or more currencies