ex_money is a lib I maintain to provide functions on and serialisation of a structured money type. It is driven by the currency definitions in the Unicode CLDR as implemented by ex_cldr.
My aim to drive to a stable 1.0 release by the end of the year. By that time CLDR release 32 will be out and ex_money will have been in the wild for several months without - so far - any material public API changes.
This post is to solicit any feedback, suggestions, concerns or issues that could contribute to the packages evolution and to the goal of a stable and production standard 1.0 release by the end of the year.
The README gives a reasonable introduction to functions and motivations. The code is available on GitHub.
Feel free to respond here. Or perhaps more appropriately open an issue on Github.
Thank you for the great work, @kip! This would be a good fit for an upcoming feature we’ll be working on at Heresy and I’ll probably put it to use in the next few weeks.
Do you see any breaking changes coming up in 1.0? If possible, could you provide some notes how to prepare for them, if we adopt the package before 1.0 is released? A migration guide would be extremely useful. Thanks!
I’ve already expressed this on github, but I really really like the approach of going from a canonical source like cldr to implementing a money library. I’ve seen money libs include some json file with currencies and their iso codes and number of decimal places, but this only works for as long you won’t need to access this data elsewhere in your application. This is different with ex_money. I can explicitly include ex_cldr in my project and use the underlying data just like ex_money does and there’s no accidental miss-match or the attempt to keep multiple sources in sync.
svilen, no planned breaking changes. My post was to solicit any feedback or requests that would potentially require a breaking change - none identified so far.
There has been a good request on GitHub for the exchange rate mechanism to allow for a “rates effective date” rather than only use “latest rates”. But that can be done backwards compatibly.
Otherwise the only plan is to make the configuration conform to the init callback mechanism like Ecto and Phoenix (its nearly there now).
Lastly, version 1.0 will be based upon CLDR version 32 which comes out next week. It doesn’t appear to change anything that would affect ex_money. The only currency change it to add the code for STN (SAO TOME AND PRINCIPE) which will be valid as of 2018-09-01. Not a big change for most apps I would say
I’ve looked at the readme and see that there are many similarities in terms of the API. Is there a particular reason to choose ex_money over money? Would it be about the exchange rates service?
I would say the main difference is that ex_money is driven by the CLDR repository and therefore supports all defined 516 locales, all ISO4217 currencies; knows the correct rounding required for each currency (cash and transaction amounts) and knows how to format in a locale-specific way.
The second difference is the provision of an Ecto composite type for Postgres (and a lesser implementation for MySQL) to aid serialisation and preserve precision.
Of course none of these things may matter for a given application.
