Target audience: Beginner
Estimated reading time: 3'
Implicit methods offer significant utility in establishing global type conversions, provided their semantics are clearly grasped. But where do implicit classes stand in this spectrum?
This article delves into the theory and practicality of Scala's implicit classes, highlighting their potential to enhance existing Scala standard libraries.
This article delves into the theory and practicality of Scala's implicit classes, highlighting their potential to enhance existing Scala standard libraries.
Notes:
- For the sake of readability of the implementation of algorithms, all non-essential code such as error checking, comments, exception, validation of class and method arguments, scoping qualifiers or import is omitted.
- The code associated with this article is written using Scala 2.11.8
Overview
Implicit methods are quite useful in defining global type conversion (as long as the semantic is clearly understood). But what about implicit classes?
Implicit classes can be used to extend existing Scala standard library classes. Most of Scala classes are declared final or implement a sealed trait. Composition is a viable alternative to Inheritance in term of re-usability: the class to extend is wrapped into a helper or utility class. However, a helper/container class adds an indirection and "pollute" the name space.
Let's look at an example of extension of standard library.
Example
The use case consists of extending the Try class, scala.util.Try with a Either semantic: Execute a function if the code throws an exception, and another function if the computation succeeds. Such simple design allows computation flows to be routed depending on unexpected state.
The main construct is the declaration of a implicit class that wraps Try. A recovery function rec is called if an exception is thrown, a computation f is performed otherwise.
1
2
3
4
5
6
7
8
9
10
11
12 | import scala.util._
implicit class Try2Either[T](_try: Try[T]) {
def toEither[U](rec: ()=>U)(f: T=>T): Either[U,T] =
_try match {
case Success(res) => Right(f(res))
case Failure(e) =>
println(e.toString)
Left(rec())
}
}
|
You may notice that the method toEither is curried to segregate the two parameterized type T and U. It also comply with the semantic of Either with Left element for error (and recovery) and Right element dedicated to the successful outcome.
Let's take the example of the normalization of a large array of floating point values by their sum. A small value will generate a rounding error during the normalization and an exception is thrown. However we do not want to burden the client code with handling the exception (the client method may not know the context of the exception after all). In this example the recovery function rec instantiates the class Recover which is responsible for a retry, potentially from a different state.
Implicit classes have an important limitation in terms of re-usability. You cannot override a default method without having to sub-class the original Scala standard library class, which is not an option in our example because Try is a sealed abstract class.
As with implicit methods, the name of the class is never actually used in the code but need to reflect the intention of the developer. Let's apply this implicit class
As with implicit methods, the name of the class is never actually used in the code but need to reflect the intention of the developer. Let's apply this implicit class
type DVector = Array[Double]
// Arbitrary recovery class
class Recover {
def reTry(x: DVector): DVector = Array[Double](0.0)
}
// Normalization of a vector. Proceeds to the
// next computation (log) if the normalization succeeds
// or invoke the recovery procedure otherwise
def normalize(x: DVector ): Either[Recover, DVector] = Try {
val sum = x.sum
if(sum < 0.01)
throw new IllegalStateException(s"sum $sum")
x.map( _ / sum)
}
.toEither(() => new Recover)( (v: DVector) => v.map( Math.log(_))
The implementation is very elegant. There is no need for new semantic and naming convention and the return type Either is very well understood in the Scala development community.
References
- Scala Cookbook - A. Alexander - O'Reilly 2013
- Scala for Machine Learning - P Nicolas Packt Publishing 2014
- Scala for Machine Learning Presentation P. Nicolas - Dec 2014
