Scala ADT encoding improvements
See original GitHub issueFor best practice with Scala ADTS:
- All case class definitions should be marked as
final
to avoid subclassing - ADT trait should be marked
extends Product with Serializable
The reason for this is that the calculated LUB for the subtypes is not just the trait, due to the extra code mixed in bycase class
orcase object
. We want the inferred type to be just the trait, this especially helps when using code which has invariant type parameters.
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Circe | ADT (Algebraic Data Types) - Scala Exercises
The most straightforward way to encode / decode ADTs is by using generic derivation for the case classes but explicitly defined instances for...
Read more >Proposal for Enumerations in Scala
Scala Improvement Process ... Today, enumerations are usually encoded via one of two mechanisms: Simply making use of Java enumerations (rarely).
Read more >Encoding ADT case classes with a discriminator, even when ...
Suppose I have a ADT in Scala: sealed trait Base case class Foo(i: Int) extends Base case class Baz(x: String) extends Base.
Read more >ADT (Algebraic Data Types) - circe
The most straightforward way to encode / decode ADTs is by using generic derivation for the case classes but explicitly defined instances for...
Read more >Generic derivation: the hard parts - Travis Brown
... and sealed traits) * Type classes (and their encoding in Scala) * Shapeless's ... recursive ADT: ```scala import io.circe.examples.derivation.simple.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
case classes are final - closing issue
Making case classes final is best practice, for many reasons.
Some people discuss this issue at https://stackoverflow.com/questions/37184528/mock-case-class-in-scala-mockito
In general, these case classes model data. Data doesn’t need to be mocked, it just is (you can create a value at any time). You probably want to be looking at the interfaces that return data, and perhaps mocking them instead.