Here in “Scala best practices I wish someone’d told me about” is how Nicolas Rinaudo describes the problem with subclassing a case class and recommends using final (he even mentions Martin Odersky) Scala best practices I wish someone'd told me about - Nicolas Rinaudo - YouTube.
Corresponding slide Scala Best Practices I Wish Someone'd Told Me About
The disagreement is purely about whether it is worth the boilerplate of explicitly saying so all the time (IMO generally not)
There are two possible answers to that.
The one I like to make, because I’m not a very nice person, is: agreed! this is also why I do not like putting types on my values. It’s not worth the boilerplate when most people know to use the right type anyway.
The better answer is: absolutely. I’m firmly in the camp of those that do not trust themselves not to make a mistake they know to avoid. I’m sometimes tired, sometimes drunk, and sometimes not even the person making editing my own code. If I can get an automated tool, such as the compiler, to do my checking for me, then so much the better! So I configured my compiler to fail on non-final case classes and never looked back. I disagree with, but respect, the notion that a little bit of boilerplate is too expensive a price to pay for getting rid of a potential tricky bug.
I couldn’t agree more.
In my own Scala experience, the software engineering dev environment is very different than the devopssec environment. And it appears that many make some pretty speculative assumptions about enterprise IT deployment environments.
I outline my own experiences with this more specifically within this response on Reddit:
https://www.reddit.com/r/scala/comments/t1hfzt/comment/hzgh8kc/?utm_source=share&utm_medium=web2x&context=3
While there is no such compiler switch built in, the wartremover compiler plugin provides such a check, see Wartremover : Built-in Warts
The concern with deserialization is interesting! I did not know. Any macros to reduce the boilerplate?