History: Why did Scala *wrap* rather than enrich Java's BigDecimal?

Language Design
1

I haven’t been able to find the origins of why the Scala std lib chose to wrap Java’s BigDecimal, rather than enrich its API with extra methods as was done with Java’s String class?

While Scala’s BigDecimal wrapper now carries around a MathContext, this can’t be the original reason. Git archeology reveals that BigDecimal was already wrapped, and then MathContext was grafted on.

At first glance, the decision to wrap seems unfortunate; it adds memory overhead and reduces compatibility, eg with JDBC. Hence, I’m trying to understand if there was a reason I’ve missed…

If we were starting out now, I’d advocate for:

  • Use Java’s BigDecimal bare
  • Add extension methods to make the API more convenient
  • Include extension operations that take a MathContext implicitly
2

BigInt was introduced long before value classes were added to Scala. And either value classes or extension methods are needed to make enrichments efficient. So wrapping was the best available technology at the time.

For String the tradeoff was different. First, interop with Java was mandatory, not just an option. Second, most String methods would be called as member methods, the enrichment added only some methods that were needed relatively infrequently.

I agree that by now we have technology with extension methods that makes enrichment the better option also for BigDecimal.

7 Likes