Open mehcode opened 2 years ago
I think the decision to have the currency type be static was a mistake. There are so many use cases where you need to deal with data that has mixed currency types. I really cannot use this library for the exact same reason. I am parsing a stream of transactions that have transactions in different currencies.
I think the decision to have the currency type be static was a mistake. There are so many use cases where you need to deal with data that has mixed currency types. I really cannot use this library for the exact same reason. I am parsing a stream of transactions that have transactions in different currencies.
agreed
I was hoping to use this library, but its not usable in any system that needs to deal with arbitrary money values - for example I have money amounts coming from protocol buffers that encode a currency code and a string value - there is no way to use this data with this library
I was also hoping to use this library, but it seems to lack iso::DEM
and due to macro usage iso cannot be added to at "our" compile time. It feels odd to have to fork it simply to add an iso.
Perhaps the real issue for my use, is that iso
and arbitrary_currency_family
do not have an enum wrapper to provide equivalence. As a result, I cannot return either an iso, or an arbitrary currency family during deserialization. If I come up with something, I'll share.
It would be a useful abstraction to allow an unknown-currency
NaiveMoney
type that works as follows:NaiveMoney
can only be constructed and converted to aMoney<C>
In the abstract, this would be for any data structure that needs to store N monetary values where the currency type is determined dynamically from some other source.
As a concrete use case, I'd like to use this to represent
MONEY
from Postgres in SQLx.Thoughts?