How crucial is Spire for supporting BigDecimal? #441
Replies: 1 comment 2 replies
-
It has to do with It's not conceptually hard, it's just that I'd have to write the conversions myself, and the number of them grows quadratically with the number of types you are supporting. Spire IS heavy-weight, which is one reason I elected to not make it a dependency of The other annoyance is that since scala Numeric and spire's conversions both overlap, but are incompatible, I could not write an "overlay" policy - you need to either import the spire conversions or core conversions, but importing both will break. On the bright side, spire's support is a superset of core support, so if you want spire it's an easy choice to make, just import the spire policies. If you wanted to write the support for BigDecimal and BigInt into the |
Beta Was this translation helpful? Give feedback.
-
@erikerlandson In the docs, you say:
You may notice that BigInt and BigDecimal are not supported in coulomb-core, even though they are Scala native types. This is because Scala's native numeric typeclasses do not uniformly treat the core types Int, Long, Float, Double the same as BigInt and BigDecimal, while spire's typeclasses do. For this reason, it is much easier to support BigInt and BigDecimal as part of the coulomb-spire package.
Can you expand on why Spire makes supporting
BigDecimal
easier? Or flipped, what would the obstacles be to supporting BigDecimal without Spire?The issue is that decimals are the standard type for any kind of monetary or financial calculation. That's a common, widespread application domain. Meanwhile, Spire is quite a heavy and complex dependency to bring in, and requiring it for any user of Coulomb who needs to work with money seems a little unfortunate.
I'm wondering if there are ways to peel BigDecimal and Spire apart..?
Beta Was this translation helpful? Give feedback.
All reactions