8 ms·

The currency codes could probably be inline value classes. That way, you can do val price = 100 money USD Note the lack of quotes around USD.

by yafetn 2y ago

sigh_again 2y ago
Maintaining an up to date currency list is, quite frankly, hell. Your code will always, always be more up to date than said list.
- 946789987649 2y ago
 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.
 - sigh_again 2y ago
 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?
- Tainnor 2y ago
 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.
 - sigh_again 2y ago
 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 plus(other: Money): Money<T> { return Money(name, amount + other.amount) } fun plus(other: Money, converter: (Money) -> 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.
 - Tainnor 2y ago
 > except throwing OOP into something that doesn't need it I feel like you're jumping to wild conclusions. All I'm suggesting is to change your code to private object EUR : Currency private object USD : Currency data class Money<C : Currency>(...) { ... } That's just an empty tag interface and that's not particularly hardcore OOP, you can do the same thing with Haskell typeclasses.

The currency codes could probably be inline value classes. That way, you can do val price = 100 money USD Note the lack of quotes around USD.

by yafetn 2y ago

The currency codes could probably be inline value classes. That way, you can do val price = 100 money USD Note the lack of quotes around USD.

sigh_again 2y ago

Maintaining an up to date currency list is, quite frankly, hell. Your code will always, always be more up to date than said list.

946789987649 2y ago
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.
- sigh_again 2y ago
  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?
Tainnor 2y ago
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.
- sigh_again 2y ago
 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 plus(other: Money): Money<T> { return Money(name, amount + other.amount) } fun plus(other: Money, converter: (Money) -> 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.
 - Tainnor 2y ago
 > except throwing OOP into something that doesn't need it I feel like you're jumping to wild conclusions. All I'm suggesting is to change your code to private object EUR : Currency private object USD : Currency data class Money<C : Currency>(...) { ... } That's just an empty tag interface and that's not particularly hardcore OOP, you can do the same thing with Haskell typeclasses.