Case objects vs Enumerations in Scala

Question

Are there any best-practice guidelines on when to use case classes  or case objects  vs extending Enumeration in Scala   They seem to offer some of the same benefits

User · Answer

I think the biggest advantage of having case classes over enumerations is that you can use type class pattern a.k.a ad-hoc polymorphysm. Don't need to match enums like:

someEnum match {
  ENUMA => makeThis()
  ENUMB => makeThat()
}

instead you'll have something like:

def someCode[SomeCaseClass](implicit val maker: Maker[SomeCaseClass]){
  maker.make()
}

implicit val makerA = new Maker[CaseClassA]{
  def make() = ...
}
implicit val makerB = new Maker[CaseClassB]{
  def make() = ...
}

User · Answer

Update March 2017  as commented by Anthony Accioly  the scala Enumeration enum PR has been closed   Dotty  next generation compiler for Scala  will take the lead  though dotty issue 1970 and Martin Odersky s PR 1958     Note  there is now  August 2016  6  years later  a proposal to remove scala Enumeration  PR 5352     Deprecate scala Enumeration  add  enum annotation      The syntax    enum  class Toggle     ON   OFF         is a possible implementation example  intention is to also support ADTs that conform to certain restrictions  no nesting  recursion or varying constructor parameters   e  g      enum sealed trait Toggle case object ON  extends Toggle case object OFF extends Toggle      Deprecates the unmitigated disaster that is scala Enumeration       Advantages of  enum over scala Enumeration          Actually works   Java interop   No erasure issues   No confusing mini-DSL to learn when defining enumerations         Disadvantages  None       This addresses the issue of not being able to have one codebase that   supports Scala-JVM  Scala js and Scala-Native  Java source code not supported on Scala js Scala-Native  Scala source code not able to define enums that are accepted by existing APIs on Scala-JVM

User · Answer

UPDATE  The code below has a bug  described here   The test program below works  but if you were to use DayOfWeek Mon  for example  before DayOfWeek itself  it would fail because DayOfWeek has not been initialized  use of an inner object does not cause an outer object to be initialized    You can still use this code if you do something like val enums   Seq  DayOfWeek   in your main class  forcing initialization of your enums  or you can use chaotic3quilibrium s modifications   Looking forward to a macro-based enum     If you want   warnings about non-exhaustive pattern matches an Int ID assigned to each enum value  which you can optionally control an immutable List of the enum values  in the order they were defined an immutable Map from name to enum value an immutable Map from id to enum value places to stick methods data for all or particular enum values  or for the enum as a whole ordered enum values  so you can test  for example  whether day  lt  Wednesday  the ability to extend one enum to create others   then the following may be of interest   Feedback welcome   In this implementation there are abstract Enum and EnumVal base classes  which you extend   We ll see those classes in a minute  but first  here s how you would define an enum   object DayOfWeek extends Enum     sealed abstract class Val extends EnumVal   case object Mon extends Val  Mon     case object Tue extends Val  Tue     case object Wed extends Val  Wed     case object Thu extends Val  Thu     case object Fri extends Val  Fri     case object Sat extends Val  Sat     case object Sun extends Val  Sun       Note that you have to use each enum value  call its apply method  to bring it to life    I wish inner objects weren t lazy unless I specifically ask for them to be   I think    We could of course add methods data to DayOfWeek  Val  or the individual case objects if we so desired   And here s how you would use such an enum   object DayOfWeekTest extends App         To get a map from Int id to enum    println  DayOfWeek valuesById         To get a map from String name to enum    println  DayOfWeek valuesByName         To iterate through a list of the enum values in definition order       which can be made different from ID order  and get their IDs and names    DayOfWeek values foreach   v   gt  println  v id           v           To sort by ID or name    println  DayOfWeek values sorted mkString          println  DayOfWeek values sortBy   toString  mkString              To look up enum values by name    println  DayOfWeek  Tue        Some DayOfWeek Val    println  DayOfWeek  Xyz        None       To look up enum values by id    println  DayOfWeek 3               Some DayOfWeek Val    println  DayOfWeek 9               None    import DayOfWeek         To compare enums as ordinals    println  Tue  lt  Fri         Warnings about non-exhaustive pattern matches    def aufDeutsch  day  DayOfWeek Val     day match       case Mon   gt   Montag      case Tue   gt   Dienstag      case Wed   gt   Mittwoch      case Thu   gt   Donnerstag      case Fri   gt   Freitag      Commenting these out causes compiler warning   match is not exhaustive       case Sat   gt   Samstag      case Sun   gt   Sonntag           Here s what you get when you compile it   DayOfWeekTest scala 31  warning  match is not exhaustive  missing combination            Sat missing combination            Sun    def aufDeutsch  day  DayOfWeek Val     day match                                              one warning found   You can replace  day match  with    day   unchecked   match  where you don t want such warnings  or simply include a catch-all case at the end   When you run the above program  you get this output   Map 0 - gt  Mon  5 - gt  Sat  1 - gt  Tue  6 - gt  Sun  2 - gt  Wed  3 - gt  Thu  4 - gt  Fri  Map Thu - gt  Thu  Sat - gt  Sat  Tue - gt  Tue  Sun - gt  Sun  Mon - gt  Mon  Wed - gt  Wed  Fri - gt  Fri  0   Mon 1   Tue 2   Wed 3   Thu 4   Fri 5   Sat 6   Sun Mon  Tue  Wed  Thu  Fri  Sat  Sun Fri  Mon  Sat  Sun  Thu  Tue  Wed Some Tue  None Some Thu  None true   Note that since the List and Maps are immutable  you can easily remove elements to create subsets  without breaking the enum itself   Here is the Enum class itself  and EnumVal within it    abstract class Enum      type Val  lt   EnumVal    protected var nextId  Int   0    private var values                List Val      private var valuesById      Map Int    Val      private var valuesByName    Map String Val       def values         values    def valuesById     valuesById    def valuesByName   valuesByName     def apply  id    Int        valuesById   get id        Some None   def apply  name  String     valuesByName get name      Some None       Base class for enum values  it registers the value with the Enum    protected abstract class EnumVal extends Ordered Val        val theVal   this asInstanceOf Val      only extend EnumVal to Val     val id   nextId     def bumpId   nextId    1       def compare  that Val     this id - that id     def apply           if   valuesById  get id     None           throw new Exception   cannot init     this     enum value twice          bumpId       values      List theVal        valuesById         id       - gt  theVal         valuesByName       toString - gt  theVal                  And here is a more advanced use of it which controls the IDs and adds data methods to the Val abstraction and to the enum itself   object DayOfWeek extends Enum      sealed abstract class Val  val isWeekday Boolean   true   extends EnumVal       def isWeekend    isWeekday     val abbrev   toString take 3       case object    Monday extends Val     Monday     case object   Tuesday extends Val    Tuesday     case object Wednesday extends Val  Wednesday     case object  Thursday extends Val   Thursday     case object    Friday extends Val     Friday     nextId   -2   case object  Saturday extends Val false   Saturday     case object    Sunday extends Val false     Sunday      val  weekDays weekendDays    values partition    isWeekday

User · Answer

I ve been going back and forth on these two options the last few times I ve needed them   Up until recently  my preference has been for the sealed trait case object option   1  Scala Enumeration Declaration  object OutboundMarketMakerEntryPointType extends Enumeration     type OutboundMarketMakerEntryPointType   Value    val Alpha  Beta   Value     2  Sealed Traits   Case Objects  sealed trait OutboundMarketMakerEntryPointType  case object AlphaEntryPoint extends OutboundMarketMakerEntryPointType  case object BetaEntryPoint extends OutboundMarketMakerEntryPointType   While neither of these really meet all of what a java enumeration gives you  below are the pros and cons   Scala Enumeration  Pros  -Functions for instantiating with option or directly assuming accurate  easier when loading from a persistent store  -Iteration over all possible values is supported   Cons  -Compilation warning for non-exhaustive search is not supported  makes pattern matching less ideal   Case Objects Sealed traits  Pros  -Using sealed traits  we can pre-instantiate some values while others can be injected at creation time -full support for pattern matching  apply unapply methods defined   Cons  -Instantiating from a persistent store - you often have to use pattern matching here or define your own list of all possible  enum values   What ultimately made me change my opinion was something like the following snippet   object DbInstrumentQueries     def instrumentExtractor tableAlias  String    s   rs  ResultSet   Instrument         val symbol   rs getString tableAlias     name       val quoteCurrency   rs getString tableAlias     quote currency       val fixRepresentation   rs getString tableAlias     fix representation       val pointsValue   rs getInt tableAlias     points value       val instrumentType   InstrumentType fromString rs getString tableAlias    instrument type        val productType   ProductType fromString rs getString tableAlias     product type         Instrument symbol  fixRepresentation  quoteCurrency  pointsValue  instrumentType  productType         object InstrumentType     def fromString instrumentType  String   InstrumentType   Seq CurrencyPair  Metal  CFD     find   toString    instrumentType  get    object ProductType      def fromString productType  String   ProductType   Seq Commodity  Currency  Index     find   toString    productType  get     The  get calls were hideous - using enumeration instead I can simply call the withName method on the enumeration as follows   object DbInstrumentQueries     def instrumentExtractor tableAlias  String    s   rs  ResultSet   Instrument         val symbol   rs getString tableAlias     name       val quoteCurrency   rs getString tableAlias     quote currency       val fixRepresentation   rs getString tableAlias     fix representation       val pointsValue   rs getInt tableAlias     points value       val instrumentType   InstrumentType withNameString rs getString tableAlias     instrument type        val productType   ProductType withName rs getString tableAlias     product type         Instrument symbol  fixRepresentation  quoteCurrency  pointsValue  instrumentType  productType          So I think my preference going forward is to use Enumerations when the values are intended to be accessed from a repository and case objects sealed traits otherwise

User · Answer

Another disadvantage of case classes versus Enumerations when you will need to iterate or filter across all instances  This is a built-in capability of Enumeration  and Java enums as well  while case classes don t automatically support such capability   In other words   there s no easy way to get a list of the total set of enumerated values with case classes

User · Answer

I have a nice simple lib here that allows you to use sealed traits classes as enum values without having to maintain your own list of values  It relies on a simple macro that is not dependent on the buggy knownDirectSubclasses   https   github com lloydmeta enumeratum

User · Answer

The advantages of using case classes over Enumerations are    When using sealed case classes  the Scala compiler can tell if the match is fully specified e g  when all possible matches are espoused in the matching declaration   With enumerations  the Scala compiler cannot tell  Case classes naturally supports more fields than a Value based Enumeration which supports a name and ID    The advantages of using Enumerations instead of case classes are    Enumerations will generally be a bit less code to write  Enumerations are a bit easier to understand for someone new to Scala since they are prevalent in other languages   So in general  if you just need a list of simple constants by name  use enumerations   Otherwise  if you need something a bit more complex or want the extra safety of the compiler telling you if you have all matches specified  use case classes

User · Answer

I ve seen various versions of making a case class mimic an enumeration   Here is my version   trait CaseEnumValue       def name String    trait CaseEnum       type V  lt   CaseEnumValue     def values List V      def unapply name String  Option String              if  values exists   name    name   Some name  else None           def unapply value V  String             return value name           def apply name String  Option V              values find   name    name            Which allows you to construct case classes that look like the following   abstract class Currency override name String  extends CaseEnumValue      object Currency extends CaseEnum       type V   Site     case object EUR extends Currency  EUR       case object GBP extends Currency  GBP       var values   List EUR  GBP      Maybe someone could come up with a better trick than simply adding a each case class to the list like I did   This was all I could come up with at the time

User · Answer

For those still looking how to get GatesDa s answer to work  You can just reference the case object after declaring it to instantiate it   trait Enum A      trait Value   self  A   gt       values     this       private var  values   List empty A    def values    values    sealed trait Currency extends Currency Value object Currency extends Enum Currency      case object EUR extends Currency     EUR   THIS IS ONLY CHANGE   case object GBP extends Currency  GBP   Inline looks better

User · Answer

UPDATE  A new macro based solution has been created which is far superior to the solution I outline below  I strongly recommend using this new macro based solution  And it appears plans for Dotty will make this style of enum solution part of the language  Whoohoo   Summary  There are three basic patterns for attempting to reproduce the Java Enum within a Scala project  Two of the three patterns  directly using Java Enum and scala Enumeration  are not capable of enabling Scala s exhaustive pattern matching  And the third one   sealed trait   case object   does   but has JVM class object initialization complications resulting in inconsistent ordinal index generation     I have created a solution with two classes  Enumeration and EnumerationDecorated  located in this Gist  I didn t post the code into this thread as the file for Enumeration was quite large   400 lines - contains lots of comments explaining implementation context     Details  The question you re asking is pretty general      when to use caseclassesobjects vs extending  scala  Enumeration   And it turns out there are MANY possible answers  each answer depending on the subtleties of the specific project requirements you have  The answer can be reduced down to three basic patterns     To start  let s make sure we are working from the same basic idea of what an enumeration is  Let s define an enumeration mostly in terms of the Enum provided as of Java 5  1 5     It contains a naturally ordered closed set of named members     There is a fixed number of members   Members are naturally ordered and explicitly indexed     As opposed to being sorted based on some inate member queriable criteria    Each member has a unique name within the total set of all members    All members can easily be iterated through based on their indexes   A member can be retrieved with its  case sensitive  name     It would be quite nice if a member could also be retrieved with its case insensitive name    A member can be retrieved with its index   Members may easily  transparently and efficiently use serialization   Members may be easily extended to hold additional associated singleton-ness data   Thinking beyond Java s Enum  it would be nice to be able to explicitly leverage Scala s pattern matching exhaustiveness checking for an enumeration     Next  let s look at boiled down versions of the three most common solution patterns posted    A  Actually directly using Java Enum pattern  in a mixed Scala Java project     public enum ChessPiece       KING  K   0      QUEEN  Q   9      BISHOP  B   3      KNIGHT  N   3      ROOK  R   5      PAWN  P   1         private char character    private int pointValue     private ChessPiece char character  int pointValue        this character   character       this pointValue   pointValue            public int getCharacter         return character         public int getPointValue         return pointValue          The following items from the enumeration definition are not available      3 1 - It would be quite nice if a member could also be retrieved with its case insensitive name   7 - Thinking beyond Java s Enum  it would be nice to be able to explicitly leverage Scala s pattern matching exhaustiveness checking for an enumeration     For my current projects  I don t have the benefit of taking the risks around the Scala Java mixed project pathway  And even if I could choose to do a mixed project  item 7 is critical for allowing me to catch compile time issues if when I either add remove enumeration members  or am writing some new code to deal with existing enumeration members    B  Using the  sealed trait   case objects  pattern    sealed trait ChessPiece  def character  Char  def pointValue  Int  object ChessPiece     case object KING extends ChessPiece  val character    K   val pointValue   0    case object QUEEN extends ChessPiece  val character    Q   val pointValue   9    case object BISHOP extends ChessPiece  val character    B   val pointValue   3    case object KNIGHT extends ChessPiece  val character    N   val pointValue   3    case object ROOK extends ChessPiece  val character    R   val pointValue   5    case object PAWN extends ChessPiece  val character    P   val pointValue   1      The following items from the enumeration definition are not available      1 2 - Members are naturally ordered and explicitly indexed   2 - All members can easily be iterated through based on their indexes   3 - A member can be retrieved with its  case sensitive  name   3 1 - It would be quite nice if a member could also be retrieved with its case insensitive name   4 - A member can be retrieved with its index     It s arguable it really meets enumeration definition items 5 and 6  For 5  it s a stretch to claim it s efficient  For 6  it s not really easy to extend to hold additional associated singleton-ness data    C  Using the scala Enumeration pattern  inspired by this StackOverflow answer     object ChessPiece extends Enumeration     val KING   ChessPieceVal  K   0    val QUEEN   ChessPieceVal  Q   9    val BISHOP   ChessPieceVal  B   3    val KNIGHT   ChessPieceVal  N   3    val ROOK   ChessPieceVal  R   5    val PAWN   ChessPieceVal  P   1    protected case class ChessPieceVal character  Char  pointValue  Int  extends super Val     implicit def convert value  Value    value asInstanceOf ChessPieceVal      The following items from the enumeration definition are not available  happens to be identical to the list for directly using the Java Enum       3 1 - It would be quite nice if a member could also be retrieved with its case insensitive name   7 - Thinking beyond Java s Enum  it would be nice to be able to explicitly leverage Scala s pattern matching exhaustiveness checking for an enumeration     Again for my current projects  item 7 is critical for allowing me to catch compile time issues if when I either add remove enumeration members  or am writing some new code to deal with existing enumeration members       So  given the above definition of an enumeration  none of the above three solutions work as they do not provide everything outlined in the enumeration definition above      Java Enum directly in a mixed Scala Java project    sealed trait   case objects    scala Enumeration     Each of these solutions can be eventually reworked expanded refactored to attempt to cover some of each one s missing requirements  However  neither the Java Enum nor the scala Enumeration solutions can be sufficiently expanded to provide item 7  And for my own projects  this is one of the more compelling values of using a closed type within Scala  I strongly prefer compile time warnings errors to indicate I have a gap issue in my code as opposed to having to glean it out of a production runtime exception failure     In that regard  I set about working with the case object pathway to see if I could produce a solution which covered all of the enumeration definition above  The first challenge was to push through the core of the JVM class object initialization issue  covered in detail in this StackOverflow post   And I was finally able to figure out a solution   As my solution is two traits  Enumeration and EnumerationDecorated  and since the Enumeration trait is over  400 lines long  lots of comments explaining context   I am forgoing pasting it into this thread  which would make it stretch down the page considerbly   For details  please jump directly to the Gist   Here s what the solution ends up looking like using the same data idea as above  fully commented version available here  and implemented in EnumerationDecorated    import scala reflect runtime universe  TypeTag typeTag  import org public domain scala utils EnumerationDecorated  object ChessPiecesEnhancedDecorated extends EnumerationDecorated     case object KING extends Member   case object QUEEN extends Member   case object BISHOP extends Member   case object KNIGHT extends Member   case object ROOK extends Member   case object PAWN extends Member    val decorationOrderedSet  List Decoration        List          Decoration KING     K   0          Decoration QUEEN    Q   9          Decoration BISHOP   B   3          Decoration KNIGHT   N   3          Decoration ROOK     R   5          Decoration PAWN     P   1           final case class Decoration private ChessPiecesEnhancedDecorated   member  Member  char  Char  pointValue  Int  extends DecorationBase       val description  String   member name toLowerCase capitalize       override def typeTagMember  TypeTag      typeTag Member    sealed trait Member extends MemberDecorated     This is an example usage of a new pair of enumeration traits I created  located in this Gist  to implement all of the capabilities desired and outlined in the enumeration definition     One concern expressed is that the enumeration member names must be repeated  decorationOrderedSet in the example above   While I did minimize it down to a single repetition  I couldn t see how to make it even less due to two issues      JVM object class initialization for this particular object case object model is undefined  see this Stackoverflow thread  The content returned from the method getClass getDeclaredClasses has an undefined order  and it is quite unlikely to be in the same order as the case object declarations in the source code    Given these two issues  I had to give up trying to generate an implied ordering and had to explicitly require the client define and declare it with some sort of ordered set notion  As the Scala collections do not have an insert ordered set implementation  the best I could do was use a List and then runtime check that it was truly a set  It s not how I would have preferred to have achieved this     And given the design required this second list set ordering val  given the ChessPiecesEnhancedDecorated example above  it was possible to add case object PAWN2 extends Member and then forget to add Decoration PAWN2  P2   2  to decorationOrderedSet  So  there is a runtime check to verify that the list is not only a set  but contains ALL of the case objects which extend the sealed trait Member  That was a special form of reflection macro hell to work through    Please leave comments and or feedback on the Gist

User · Answer

I prefer case objects  it s a matter of personal preference   To cope with the problems inherent to that approach  parse string and iterate over all elements   I ve added a few lines that are not perfect  but are effective   I m pasting you the code here expecting it could be useful  and also that others could improve it          Enum for Genre  It contains the type  objects  elements set and parse method        This approach supports        - Pattern matching    - Parse from name    - Get all elements     object Genre     sealed trait Genre    case object MALE extends Genre   case object FEMALE extends Genre    val elements   Set  MALE  FEMALE     You have to take care this set matches all objects    def apply  code  String        if  MALE toString    code  MALE     else if  FEMALE toString    code  FEMALE     else throw new IllegalArgumentException           Enum usage  and tests       object GenreTest extends App     import Genre      val m1   MALE   val m2   Genre   MALE      assert  m1    m2    assert  m1 toString     MALE      val f1   FEMALE   val f2   Genre   FEMALE      assert  f1    f2    assert  f1 toString     FEMALE      try       Genre  null      assert  false        catch       case e  IllegalArgumentException   gt  assert  true         try       Genre   male       assert  false        catch       case e  IllegalArgumentException   gt  assert  true         Genre elements foreach   println

User · Answer

One big difference is that Enumerations come with support for instantiating them from some name String  For example  object Currency extends Enumeration      val GBP   Value  quot GBP quot      val EUR   Value  quot EUR quot     etc      Then you can do  val ccy   Currency withName  quot EUR quot    This is useful when wishing to persist enumerations  for example  to a database  or create them from data residing in files  However  I find in general that enumerations are a bit clumsy in Scala and have the feel of an awkward add-on  so I now tend to use case objects  A case object is more flexible than an enum  sealed trait Currency   def name  String   case object EUR extends Currency   val name    quot EUR quot      etc   case class UnknownCurrency name  String  extends Currency  So now I have the advantage of    trade ccy match     case EUR                     gt    case UnknownCurrency code    gt     As  chaotic3quilibrium pointed out  with some corrections to ease reading    Regarding  quot UnknownCurrency code  quot  pattern  there are other ways to handle not finding a currency code string than  quot breaking quot  the closed set nature of the Currency type  UnknownCurrency being of type Currency can now sneak into other parts of an API  It s advisable to push that case outside Enumeration and make the client deal with an Option Currency  type that would clearly indicate there is really a matching problem and  quot encourage quot  the user of the API to sort it out him herself   To follow up on the other answers here  the main drawbacks of case objects over Enumerations are   Can t iterate over all instances of the  quot enumeration quot   This is certainly the case  but I ve found it extremely rare in practice that this is required   Can t instantiate easily from persisted value  This is also true but  except in the case of huge enumerations  for example  all currencies   this doesn t present a huge overhead

User · Answer

Case objects already return their name for their toString methods  so passing it in separately is unnecessary   Here is a version similar to jho s  convenience methods omitted for brevity    trait Enum A      trait Value   self  A   gt      val values  List A     sealed trait Currency extends Currency Value object Currency extends Enum Currency      case object EUR extends Currency   case object GBP extends Currency   val values   List EUR  GBP      Objects are lazy  by using vals instead we can drop the list but have to repeat the name   trait Enum A  lt    def name  String       trait Value   self  A   gt       values     this       private var  values   List empty A    def values    values    sealed abstract class Currency val name  String  extends Currency Value object Currency extends Enum Currency      val EUR   new Currency  EUR        val GBP   new Currency  GBP          If you don t mind some cheating  you can pre-load your enumeration values using the reflection API or something like Google Reflections   Non-lazy case objects give you the cleanest syntax   trait Enum A      trait Value   self  A   gt       values     this       private var  values   List empty A    def values    values    sealed trait Currency extends Currency Value object Currency extends Enum Currency      case object EUR extends Currency   case object GBP extends Currency     Nice and clean  with all the advantages of case classes and Java enumerations   Personally  I define the enumeration values outside of the object to better match idiomatic Scala code   object Currency extends Enum Currency  sealed trait Currency extends Currency Value case object EUR extends Currency case object GBP extends Currency

User · Answer

If you are serious about maintaining interoperability with other JVM languages  e g  Java  then the best option is to write Java enums   Those work transparently from both Scala and Java code  which is more than can be said for scala Enumeration or case objects   Let s not have a new enumerations library for every new hobby project on GitHub  if it can be avoided

[scala] Case objects vs Enumerations in Scala

Examples related to scala

Examples related to enumeration

Examples related to case-class