This could be mitigated by making the currency interface / abstract class open to extension by the user. The common currencies would be provided by the library and any additional ones could be defined by the user.
Making currencies a concrete implementation is a terrible idea. There is no benefit to it at all, except throwing OOP into something that doesn't need it. A single Money class covers all needed cases, the difference between USD and BTC is... everything. Different smallest denominations, different formats, different everything. You don't even need concrete implementations
private data class Money<T>(val name: String, val amount: Int) {
operator fun <U : T> plus(other: Money<U>): Money<T> {
return Money(name, amount + other.amount)
}
fun <U> plus(other: Money<U>, converter: (Money<U>) -> Money<T>): Money<T> {
return converter(other) + this
}
}
private object EUR
private object USD
val eur = Money<EUR>("EUR", 10)
val usd = Money<USD>("USD", 20)
usd + eur // error
This gives you entirely user defined currencies, does not pollute the global scope with unneeded currencies, allows you to plug in any conversion technique (pop off, make a network call), and fails if you try to add USD and EUR without converting one into the other.
Currencies should always be the user's responsibility to provide.
You could argue the same for timezones in a date library, yet they have them. I would think a library dedicated to money will in fact be the most up to date.
Do they ? I've never once had a library that stores Europe_Paris, or Offset_Plus_7_45, they've always been stringly typed. Do you have an example of who'd be crazy enough to maintain a wrapper around tzdb?