2 ms·

… there's a number of (rather trivial?) fixes to some of the problems they hit. First, you can have a type-checker check the currency; that doesn't have to be

… there's a number of (rather trivial?) fixes to some of the problems they hit. First, you can have a type-checker check the currency; that doesn't have to be a runtime error: Money<Usd> m = …; There will, of course, be instances where you must handle currency dynamically. "MoneyExpr" is a bit more complicated; I find most people usually implement "MoneyBag" intuitively first, so it's odd they left that for third? So, the article gets there, and we "fix" the problems, but it feels roundabout. The criticism of MoneyBag is bizarre: > Compared to the Martin Fowler’s design, it remains heavier. It consumes more memory and more CPU This is apples to oranges? Fowler's design is a Money type; MoneyBag is a different thing; of course it consumes more memory. A Vec<int> consumes more memory than an int, too? Perhaps the article author isn't comfortable with that Money merely isn't closed over addition. But if you accept that Money isn't closed over addition, then naturally there must be another type in the type system.

naasking 3y ago
I'm not sure what the confusion is, the question being explored is, "how do you define a Money type that features the operations we typically expect to perform and with the results having the expected properties?". He reviews various well-known published designs and their drawbacks, and outlines a design that does not have those drawbacks. > I find most people usually implement "MoneyBag" intuitively first, so it's odd they left that for third? I have not found that at all.
AEVL 3y ago
> First, you can have a type-checker check the currency; that doesn't have to be a runtime error: > Money<Usd> m = …; > There will, of course, be instances where you must handle currency dynamically. With dependent types, checking for currency validity may be handled at compile-time. (This is touched upon in the post linked in the comment you replied to.) For the case of conversion between currencies of monetary amounts: https://github.com/anderslundstedt/type-experiments#type-safe-currency-conversions https://github.com/anderslundstedt/type-experiments#type-saf...

naasking 3y ago

I'm not sure what the confusion is, the question being explored is, "how do you define a Money type that features the operations we typically expect to perform and with the results having the expected properties?". He reviews various well-known published designs and their drawbacks, and outlines a design that does not have those drawbacks. > I find most people usually implement "MoneyBag" intuitively first, so it's odd they left that for third? I have not found that at all.

AEVL 3y ago

> First, you can have a type-checker check the currency; that doesn't have to be a runtime error: > Money<Usd> m = …; > There will, of course, be instances where you must handle currency dynamically. With dependent types, checking for currency validity may be handled at compile-time. (This is touched upon in the post linked in the comment you replied to.) For the case of conversion between currencies of monetary amounts: https://github.com/anderslundstedt/type-experiments#type-safe-currency-conversions https://github.com/anderslundstedt/type-experiments#type-saf...