A quick search shows we have a handful of final case classes, but most are not so marked.
I think this makes sense as a coding standard. I am not always strict about this, but I tend to believe if you are deriving from a class it usually should be abstract, not concrete, and case classes are always concrete. The rest of the essay is worth review, but I'm not so sure I want to convert case classes to this. It simply adds far too much code. Diving down this rathole however, I leared numerous things. 1) There is a ScalaCache library - possibly useful 2) The implementation of equals and hashcode is quite tricky, and we've certainly done it sub-optimally a few places. It is actually quite problematic, as you cannot do it right without knowing whether any superclass has already overloaded equals and hashcode itself or not. 3) There is a foo.## method. The method name is "##" and it is used when computing hashcodes. But making case clases final is not controvercial. I think there are hundreds, so we should do that as a single PR. On Mon, Feb 28, 2022 at 9:23 AM Interrante, John A (GE Research, US) < [email protected]> wrote: > The latest Scala Times newsletter included this link to an article called > Effective Scala Case Patterns: > > Article: Effective Scala Case Class Patterns - The guide I wished I had > read years ago when starting my Scala journey (github.com)< > https://gist.github.com/chaotic3quilibrium/58e78a2e21ce43bfe0042bbfbb93e7dc > > > > The article criticizes the default case class pattern as we use it in > Daffodil and says adding a companion object to the case class can fix > issues such as elevated reasoning complexity, poor FP design, future > technical debt, and security vulnerabilities. It's interesting reading, > but it proposes adding extra code that you'd need only if your case classes > can be constructed with invalid state (the purpose of the companion object > is to detect and prevent the invalid state before constructing the class > class). However, adding final to all case classes to prevent extension > confusion may be worthwhile. > > John >
