Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>One big difference is that <code>Enumeration</code>s come with support for instantiating them from some <code>name</code> String. For example:</p> <pre><code>object Currency extends Enumeration { val GBP = Value("GBP") val EUR = Value("EUR") //etc. } </code></pre> <p>Then you can do:</p> <pre><code>val ccy = Currency.withName("EUR") </code></pre> <p>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 <code>case object</code>s. A <code>case object</code> is more flexible than an enum:</p> <pre><code>sealed trait Currency { def name: String } case object EUR extends Currency { val name = "EUR" } //etc. case class UnknownCurrency(name: String) extends Currency </code></pre> <p>So now I have the advantage of...</p> <pre><code>trade.ccy match { case EUR =&gt; case UnknownCurrency(code) =&gt; } </code></pre> <p>As <a href="https://stackoverflow.com/users/501113/chaotic3quilibrium">@chaotic3quilibrium</a> pointed out (with some corrections to ease reading):</p> <blockquote> <p>Regarding "UnknownCurrency(code)" pattern, there are other ways to handle not finding a currency code string than "breaking" the closed set nature of the <code>Currency</code> type. <code>UnknownCurrency</code> being of type <code>Currency</code> can now sneak into other parts of an API.</p> <p>It's advisable to push that case outside <code>Enumeration</code> and make the client deal with an <code>Option[Currency]</code> type that would clearly indicate there is really a matching problem and "encourage" the user of the API to sort it out him/herself.</p> </blockquote> <p>To follow up on the other answers here, the main drawbacks of <code>case object</code>s over <code>Enumeration</code>s are:</p> <ol> <li><p><em>Can't iterate over all instances of the "enumeration"</em>. This is certainly the case, but I've found it extremely rare in practice that this is required.</p></li> <li><p><em>Can't instantiate easily from persisted value</em>. This is also true but, except in the case of huge enumerations (for example, all currencies), this doesn't present a huge overhead.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload