Dribbling about Scala Value Classes, Universal Traits and Extension methods

Extension Methods, Scala, Universal Traits, Value Classes, , ,

In this blog , I will share my working knowledge on Value Classes, Universal Traits and Extension methods of Scala.

Let’s start with the Value Classes of Scala. In this section we will talk about Value Classes Introduction, Use Case and it’s limitations.

Value classes have been around in Scala for a long time internally, and we have used them already many times because all Number’s in Scala use this compiler trick to avoid boxing and unboxing numeric values from int to scala.Int etc.

As a quick reminder, let’s recall that Array[Int] is an actual JVM int[] which has tons of performance implications, but in one word — arrays of numbers are fast, arrays of references not as much.

In more specific technical terms Value classes are a new mechanism in Scala to avoid allocating runtime objects. This is accomplished through the definition of new AnyVal subclasses. They were proposed in SIP-15.

value-classes

Ok, since we now know the compiler has fancy tricks to avoid boxing ints into Ints when it doesn’t have to. Let’s see how this feature is exposed for us, end users since Scala 2.10.x. The feature is called “value classes”, is fairly simple to apply to your existing classes. Using them is as simple as adding extends AnyVal to your class and following a few rules listed bellow.

  • Value Class must have only a primary constructor with exactly one public, val parameter whose type is not a value class. (From Scala 2.11.0, the parameter may be non-public.)
  • Value Class may not have specialized type parameters.
  • Value Class may not have nested or local classes, traits, or objects
  • Value Class may not define a equals or hashCode method.
  • Value Class must be a top-level class or a member of a statically accessible object
  • Value Class can only have defs as members. In particular, it cannot have lazy vals, vars, or vals as members.
  • Value Class cannot be extended by another class.

Now we have enough descriptions about Value classes. Let’s go with a simple example of it. I will be using Case (Value) Classes in all my examples here, but it’s not technically required to do so. We can implement a Value Class using a normal class with one val parameter instead, but using case classes is usually the best way to go.

case class Hour(value: Double) extends AnyVal {
  def toMinute: Minute = Minute(value * 60)
}

case class Minute(value: Double) extends AnyVal {
  def toHour: Hour = Hour(value / 60)
}

Now we need to know about two important keywords related to Value Classes which is Universal Traits and Extension methods.

  • A universal trait is a trait that extends Any, only has def s as members, and does no initialization. Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation.
  • Extension methods serve the same purpose as Implicit conversions (which are a more general and more powerful utility), yet are better than conversions in one simple way — they avoid having to allocate the “Wrapper” object, which implicit conversions would otherwise use to provide the “added methods”. Extension methods take the route of rewriting the generated methods a little, so that they take the type-to-be-extended as their 1st argument.

These are the basics around Value Classes, Universal traits and Extension methods. If you want to read more about the different edge-cases around them, please refer to the official documentaion’s section about Value Classes where Mark Harrah, explains them very well with tons of examples, so I won’t be duplicating his effort here beyond the basic introduction 🙂 . As next step, I would look at how I can explain the use case of Value Classes and It’s functionality 🙂 Stay tuned.

Leave a comment