Interesting reading: Effective Scala Case Class Patterns

["Interrante, John A (GE Research, US)" <Jo...@ge.com>]

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

Re: Interesting reading: Effective Scala Case Class Patterns

[Mike Beckerle <mb...@apache.org>]

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) <
John.Interrante@ge.com> 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
>