…the 6 that have 3 decimal places and the one that has 4 decimal places.
I had no idea such currencies exist
And obviously neither does anyone proposing to deal with money by
reducing all amounts to integers 
hassan
0
AstonJ
Using integers is perfectly fine for most currencies when decimal isn’t an option - at least from everything I’ve read about it.
What would you suggest if decimal wasn’t an option?
0
sztosz
No I didn’t 
But I think that every currency has to by strongly typed, and have not only it’s value but also a mean to distinguish it from other currencies, so the conversion from the internal representation i.e. integers to an external representation does really rely on its type (is it US Dollar, Libyan dinar, Chilean unit of account, or rather something even more exotic for the majority of library users). Representing value internally by decimal type, can lead to nasty undesirable state, like having a 1.005 value for currencies that does not have 3rd digit in fractions. On the other hand we wouldn’t want automatic rounding…
Counting money is hard, maybe not as hard as dealing with time, but still…
1
hassan
Using integers is perfectly fine for most currencies when decimal isn’t an
option - at least from everything I’ve read about it.
Not in my opinion – you will always have to deal with fractional
values and rounding at some point.
2
kip
ex_cldr Core Team
I believe that when dealing with money it’s important to
-
Always have a currency associated with any amount. Assumptions lead to issues including but not limited to rounding and arithmetic. Indeed some currencies round differently for cash values versus accounting values (for example the Australian dollar has a minimum 5c unit for cash and 1c for accounting/electronic transactions).
-
The value needs to be either a Decimal (fixed point) or an integer plus an exponent (which is how the Decimal lib works anyway).
In Postgres you can represent these opinions with a composite type (which is what I do in ex_money | Hex) which Ecto supports out-of-the-box. For MySql its a bit trickier and I use a json field with the decimal amount serialised as a string value to preserve precision.
6
AstonJ
Thanks for the replies all… I’m glad I only had to think about pound sterling when I was working on an app that dealt with money (we used decimal)
1
pkrawat1
Yeah, we were looking for such library, but could not found one. So thought to give it a try. Thanks to the team effort we reached this stage.
Floats: - Oh that was really a great remark, Thanks. we can use some thing like money, ex_money and monetized suggested by kip , that are using decimal as the amount.
we are also thinking about adding a cryptocurrency gateway here. Then decimal would be the ideal solution for it. Will think about this.
Genserver: - We are still thinking about, giving the control to the end user or keeping the control to us, in relation to handling multiple requests like subscriptions in workers. Not sure right now. Since we are focusing on adding minimal gateways(6) first. So this time would be great to think about the supervision tree incase it is required or not, or just modules and functions will do.
Since the project is just some weeks old. Things/thoughts will come. Wanted to share it with you guys. Suggestions like these are the way to make a great library.
1
pkrawat1
Thanks for the suggestion. We really need an abstraction here for money types.
Awesome, you are the author of ex_money.
0
pkrawat1
we are thinking of adding support for subscription and refunds too. Looking for community response regarding this.
we will be adding a road map on readme. Currently we are following Active Merchant strategy and gateways it provides.
0
pkrawat1
I had worked on a fin-tech project for mutual funds, stocks, bonds etc. Even decimals were giving us nightmares, as digits at 9 decimal places were important. And ruby was not doing it correctly at those decimal places, or may be we were missing something. But we had to fix the decimal places later in the end .
1