# Monoids are not demode and thursdays are actually the new fridays

No, it’s not the latest Coixet’s movie title. When we talk about cathegories like monoids, we tend to think they just remain on the edge as something merely experimental (even though purely functional) and there’s no direct application at the real world. Something similar happened when you learnt square roots at school and there was no proper moment to start using them at real life…

## The use case

This morning, ah naïve me, I tried to make this work:

```type Passengers = Int
type MaxCapacity = Passengers
type Plane = (Passengers, MaxCapacity)

val planes: List[Plane] =
List(1 -> 1, 2 -> 3, 3 -> 3)

val (totalPassengers, totalCapacity) =
planes.sum
//  ERROR: Could not find implicit value
//  for parameter num: Numeric[(Int, Int)]
```

Ok, fair enough, Scala needs something, an evidence, for adding integer tuples.
Before we start fighting with the ‘evidence’, let’s try to make it work in a more mechanical way:

```val sum = ((0,0) /: planes){
case ((totalPas,totalCap), (passengers, capacity)) =>
(totalPas + passengers, totalCap + capacity)
}
```

Okay, it works. But it should be simpler, so let’s get back to the idea of `Numeric[N]` evidence.

## Implementing `Numeric[N]`

We need a `Numeric[(A,B)]` but before implementing it (it has a lot of abstract methods) let’s sweep under the rug all those methods we don’t really want to focus on in this example. For doing so, let’s create an intermediate layer that keeps all those method without an implementation (which doesn’t mean ‘abstract’):

```trait LeanNumeric[T] extends Numeric[T] {
override def fromInt(x: Int): T = ???
override def toInt(x: T): Int = ???
override def minus(x: T, y: T): T = ???
override def times(x: T, y: T): T = ???
override def negate(x: T): T = ???
override def toLong(x: T): Long = ???
override def toFloat(x: T): Float = ???
override def toDouble(x: T): Double = ???
override def compare(x: T, y: T): Int = ???
}
```

Let’s call this abomination LeanNumeric (it only contains the essentials to develop our example). And now, we can define the method that generates the evidence for any `Tuple2`:

```implicit def numeric[A, B](
implicit nA: Numeric[A],
nB: Numeric[B]): Numeric[(A, B)] = {
new LeanNumeric[(A, B)]{
override def zero = (nA.zero, nB.zero)
override def plus(x: (A, B), y: (A, B)): (A, B) = {
val (a1, b1) = x
val (a2, b2) = y
(nA.plus(a1, a2), nB.plus(b1, b2))
}
}
}
```

If we put the implicit into scope and we run again `planes.sum`…boom! Magic.

## Num…oid

We don’t have to master category theory to realize that `Numeric[N]` may be a thousand of things, but it satisfies at least two properties:

• The append operation: The sum operation – given n1 and n2 of type N, it return a new N element. Only because of this feature(and the closure, associativity, commutative, …) we can consider it a Semigroup.

• And additionally the zero element

Seriously? Isn’t it obvious enough? My dear friends, monoid is back in town!

## Implementation with `scalaz.Monoid`

Having in mind that Numeric has (at least) these two properties, let’s re-implement the implicit by using scalaz Monoid. We first define the monoid for integers and the tuple monoid which requires a monoid for each type that compounds the tuple (easy peasy):

```import scalaz._

implicit object IntMonoid extends Monoid[Int]{
override def zero: Int = 0
override def append(f1: Int, f2: => Int): Int = f1 + f2
}

implicit def tupleMonoid[A,B](
implicit mA: Monoid[A],
mB: Monoid[B]): Monoid[(A,B)] = {
new Monoid[(A, B)] {
override def zero: (A, B) = (mA.zero, mB.zero)
override def append(f1: (A, B), f2: => (A, B)): (A, B) = {
val (a1, b1) = f1
lazy val (a2, b2) = f2
(mA.append(a1,a2), mB.append(b1, b2))
}
}
}
```

So good so far, right?

After that, we implement the implicit that will provide a Numeric as long as there’s a Monoid for the type

```implicit def numeric[T](
implicit m: Monoid[T]): Numeric[T] = {
new LeanNumeric[T]{
override def zero = m.zero
override def plus(x: T, y: T): T = m.append(x, y)
}
}

planes.sum //(6,7)
```

And it’s awesomely easy to get abstract of whatever T means (a tuple? a dog? …). As long as it’s a monoid, you can define a LeanNumeric.

You can find here the gist.

See you in the next functional madness.

Peace out!

# Los monoides no están demodé y los jueves sí son los nuevos viernes

No, no es el título de la nueva película de Coixet. Cuando hablamos de categorías como los monoides, tendemos a pensar que se quedan en el ámbito de lo experimental (aunque funcionalmente puro) y que no existe aplicación directa sobre el mundo real. Algo parecido a lo que ocurría cuando te enseñaban a hacer raíces cuadradas en el colegio y no veías el momento para usarlo en la vida real…

## El caso de uso

Esta misma mañana, ingenuo de mi, intentaba hacer que funcionara lo siguiente:

```type Passengers = Int
type MaxCapacity = Passengers
type Plane = (Passengers, MaxCapacity)

val planes: List[Plane] =
List(1 -> 1, 2 -> 3, 3 -> 3)

val (totalPassengers, totalCapacity) =
planes.sum
//  ERROR: Could not find implicit value
//  for parameter num: Numeric[(Int, Int)]
```

Vale, comprensible, Scala necesita algo, una evidencia, para poder sumar tuplas de enteros.
Antes de pegarnos con la “evidencia”, intentemos hacerlo funcionar de una manera mucho más mecánica:

```val sum = ((0,0) /: planes){
case ((totalPas,totalCap), (passengers, capacity)) =>
(totalPas + passengers, totalCap + capacity)
}
```

Okay, funciona. Pero debería ser algo más simple, por lo que retomemos la idea de la evidencia `Numeric[N]`.

## Implementando `Numeric[N]`

Necesitamos un `Numeric[(A,B)]` pero antes de implementarlo (tiene bastantes métodos abstractos) escondamos debajo de la alfombra aquellos métodos en los cuales no queremos centrarnos en este ejemplo. Para ello creamos una capa por encima que deje los métodos sin implementar (que no abstractos):

```trait LeanNumeric[T] extends Numeric[T] {
override def fromInt(x: Int): T = ???
override def toInt(x: T): Int = ???
override def minus(x: T, y: T): T = ???
override def times(x: T, y: T): T = ???
override def negate(x: T): T = ???
override def toLong(x: T): Long = ???
override def toFloat(x: T): Float = ???
override def toDouble(x: T): Double = ???
override def compare(x: T, y: T): Int = ???
}
```

A esta aberración la llamaremos LeanNumeric (solo contiene lo esencial para desarrollar nuestro ejemplo). Y ahora definimos el método que genera la evidencia para cualquier `Tuple2`:

```implicit def numeric[A, B](
implicit nA: Numeric[A],
nB: Numeric[B]): Numeric[(A, B)] = {
new LeanNumeric[(A, B)]{
override def zero = (nA.zero, nB.zero)
override def plus(x: (A, B), y: (A, B)): (A, B) = {
val (a1, b1) = x
val (a2, b2) = y
(nA.plus(a1, a2), nB.plus(b1, b2))
}
}
}
```

Si ponemos el implícito en scope y ejecutamos de nuevo el `planes.sum`…¡boom! Magia.

## Num…oide

No hace falta saber mucho de teoría de categorías para centrarse en que `Numeric[N]`, podrá ser mil cosas más, pero cumple dos propiedades:

• La operación append : La operación suma – dados n1 y n2 de tipo N, devuelve otro elemento N. Solo por disponer de esta operación (y el clossure, la asociatividad, la conmutativa, …) ya podemos considerarlo un Semigroup

• Y adicionalmente el elemento zero : genera el elemento neutro de la suma

¿en serio?¿No es evidente?…amigos, ¡el monoide ha vuelto a la ciudad!

## Implementación con `scalaz.Monoid`

Viendo que el tipo Numeric tiene al menos esas dos propiedades, re-implementamos el implícito haciendo uso de Monoid. Primero definimos el monoide para enteros y el monoide de las tuplas,
el cual requiere de un monoide para cada tipo que compone la tupla (easy peasy)

```import scalaz._

implicit object IntMonoid extends Monoid[Int]{
override def zero: Int = 0
override def append(f1: Int, f2: => Int): Int = f1 + f2
}

implicit def tupleMonoid[A,B](
implicit mA: Monoid[A],
mB: Monoid[B]): Monoid[(A,B)] = {
new Monoid[(A, B)] {
override def zero: (A, B) = (mA.zero, mB.zero)
override def append(f1: (A, B), f2: => (A, B)): (A, B) = {
val (a1, b1) = f1
lazy val (a2, b2) = f2
(mA.append(a1,a2), mB.append(b1, b2))
}
}
}
```

Hasta aquí bien, ¿correcto?

Implementemos ahora el implícito que nos proporcionará un Numeric siempre que exista un Monoid para el tipo

```implicit def numeric[T](
implicit m: Monoid[T]): Numeric[T] = {
new LeanNumeric[T]{
override def zero = m.zero
override def plus(x: T, y: T): T = m.append(x, y)
}
}

planes.sum //(6,7)
```

Y es increiblemente sencillo abstraerse de lo que demonios sea T (¿una tupla?, ¿un perro?, …).
Mientras sea un monoide, se puede definir un LeanNumeric.

Podéis encontrar aquí el gist resumen

Hasta la próxima locura funcional.

¡Agur de limón!

# Scalera tip: Handling sticky implicit contexts

A couple of days ago (translation for the masses: like a month ago) I noticed Viktor Klang was tweeting about removing the annoying implicit evidences from methods. And some things I read seemed so elegant to me that I was forced to share some related ideas with all of you that don’t follow him at Twitter (@viktorklang).

## Setting some context

Imagine the typical polymorphic method where we need an execution context for evaluating some Future:

```import scala.concurrent.{ExecutionContext, Future}

def myMethod[T]
(element: T)
(implicit ev: ExecutionContext): Future[Boolean] = ???
```

You could say it’s as typical as disgusting, having to repeat the same exact words in the following 10 method definitions: `(implicit ev: ExecutionContext)`.

## Playing with type alias

The happy idea that is being proposed is to define a type alias like the following one:

```type EC[_] = ExecutionContext
```

This way, by adding some syntax sugar, we would re-define the method signature:

```def myMethod[T:EC](element: T): Future[Boolean] = ???
myMethod("hi")
```

Beautiful, isn’t it?

## Some other possibilities

### Non-polymorphic methods

In case our method isn’t parameterized, we would have to add some boilerplate (by adding a wildcard for the type that parameterizes the method). In essence, it should be working the same principle:

```def myMethod[_:EC](element: Int): Future[Boolean] = ???
myMethod(2)
```

### Multiple implicit contexts

The not-so-crazy case in which we needed several implicit parameters of different natures, we would have to define as many type alias as different type parameters we required:

```type EC[_] = ExecutionContext
type MongoDB[_] = MongoDBDatabase

def myMethod[_:EC:MongoDB](element: Int): Future[Boolean] = ???
```

## But what if …?

### Multiple implicit parameters with same type

In case we have several implicit parameters that share the same type,

```def myMethod
(element: Int)
(implicit ev1: ExecutionContext, ev2: ExecutionContext): Future[Boolean] = ???
```

it turns out that …

Well, by definition that’s impossible given that it would incur in some ambiguity issue when resolving implicits. It’s true that Scala allows having these kind of signatures, but we could only invoke them by making explicit the arguments contained in the second parameter group.:

```myMethod(2)(ec1,ec2)
```

which is kind of…

### Type-constructor implicit contexts

When we have implicit parameters that are also type constructors like `List[T], Future[T], Option[T]`

…well, it actually depends.

#### Case 1

If the type that parameterizes the method and the one that parameterizes the evidence are not related, there’s no big deal: we define another type alias and move on:

```type EC[_] = ExecutionContext
type MongoDB[_] = MongoDBDatabase
type IntOpt[_] = Option[Int]
type StrList[_] = List[String]

def myMethod[_:EC:MongoDB:IntOpt:StrList](
element: Int): Future[Boolean] = ???
```

Which would be equivalent to:

```def myMethod(
element: Int)(
implicit ev1: ExecutionContext,
ev2: MongoDBDatabase,
ev3: Option[Int],
ev4: List[String]): Future[Boolean] = ???
```

#### Case 2

If the type that parameterizes the method and the one that parameterizes the evidence have to match …

Well, it’s not possible. The syntax sugar we’re using here implies that both types have to match. Maybe it was too pretty for our bodies 🙂

See you in the next post. Peace out!

# Scalera tip: contextos implícitos pegajosos

El otro día (para la gente normal: hace cosa de 1 mes) vi que el gran Viktor Klang twiteaba acerca de como quitar las molestas evidencias implícitas en definiciones de métodos. Y me pareció tan elegantes algunas de las cosas que leí, que me vi en la obligación de compartir algunas ideas al hilo de dichos consejos con aquellos de vosotros que no le sigáis aun en Twitter (@viktorklang).

## La situación

Imaginad el típico método polimórfico en el cual necesitamos un execution context para ejecutar un futuro:

```import scala.concurrent.{ExecutionContext, Future}

def myMethod[T]
(element: T)
(implicit ev: ExecutionContext): Future[Boolean] = ???
```

Es tan típico como feo, el tener que repetir la coletilla de `(implicit ev: ExecutionContext)` en 10 métodos seguidos…

## Jugando con type alias

La idea feliz que se propone es definir un type alias del siguiente tipo:

```type EC[_] = ExecutionContext
```

De esta forma, re-definiríamos la cabecera de nuestro método como sigue:

```def myMethod[T:EC](element: T): Future[Boolean] = ???
myMethod("hi")
```

¿Bello o no?

### Métodos no polifórmicos

En el caso en que nuestro método no esté parametrizado, tendríamos que añadir algo de boilerplate (añadiendo un wildcard para el tipo que parametriza el método), pero en esencia debería seguir funcionando el mismo principio:

```def myMethod[_:EC](element: Int): Future[Boolean] = ???
myMethod(2)
```

### Múltiples contextos implícitos

En el no-tan-descabellado caso en el que necesitáramos varios parámetros implícitos de distintos tipos, necesitaríamos definir tantos type alias como tipos distintos de parámetros requiriésemos:

```type EC[_] = ExecutionContext
type MongoDB[_] = MongoDBDatabase

def myMethod[_:EC:MongoDB](element: Int): Future[Boolean] = ???
```

## Pero, ¿y si…?

### Múltiples parámetros implícitos del mismo tipo

En el caso de que tengamos múltiples parámetros implícitos del mismo tipo,

```def myMethod
(element: Int)
(implicit ev1: ExecutionContext, ev2: ExecutionContext): Future[Boolean] = ???
```

ocurriría que …

Bueno, por definición eso es imposible ya que incurriría en un problema de ambigüedad a la hora de resolver implícitos. Es cierto que Scala nos permite este tipo de signaturas, pero sólo podríamos invocar al método haciendo explícitos los argumentos del segundo grupo de parámetros:

```myMethod(2)(ec1,ec2)
```

Lo cual es un tanto…

### Contextos implícitos que son constructores de tipos

Cuando tenemos parámetros implícitos que son constructores de tipos como `List[T], Future[T], Option[T]`

#### Caso1

Si el tipo que parametriza el método y el que parametriza la evidencia no están relacionados, no hay mucho problema: definimos otro type alias y a correr:

```type EC[_] = ExecutionContext
type MongoDB[_] = MongoDBDatabase
type IntOpt[_] = Option[Int]
type StrList[_] = List[String]

def myMethod[_:EC:MongoDB:IntOpt:StrList](
element: Int): Future[Boolean] = ???
```

Lo cual sería el equivalente a:

```def myMethod(
element: Int)(
implicit ev1: ExecutionContext,
ev2: MongoDBDatabase,
ev3: Option[Int],
ev4: List[String]): Future[Boolean] = ???
```

#### Caso 2

Si el tipo que parametriza el método y el que parametriza la evidencia tienen que concordar …

Bueno no es posible. El syntax sugar implica que el tipo que parametriza el método vaya en concordancia con el tipo que parametriza nuestra evidencia. Quizás era todo demasiado bonito 🙂

Hasta el próximo post. ¡Agur de limón!

# Algrebraic Data Types in Scala

What a delightful idea to come back from vacation with batteries fully charged and with some wacky ideas around our minds to write about. Best of these came from the very influence of joints the moon.

An Algebraic Data Type (TDA from now so we can save money for each word in WordPress) is just a way to express a data type (Cat, Dog, Prevarication) based on an algebra. And when we say ‘algebra’, we mean type sums and products (of Integers, Cats, Cars, Prevarications, …). For example:

```Train = Locomotive + Wagon * Train
```

How do one read that? A train may be: a locomotive OR a wagon AND another train (that may be as well a wagon and another train, that may be as well a …).
Take a look at both disjunction and conjunction: the sum represents an OR, and the product represents an AND (like Boole algebra).

It’s also worthy to notice that, from this type definition you can infer a recursive pattern. With the Train type, the base case is definitively the Locomotive and, at the recursive case, we have a wagon and another train. As we’ll see later, this pattern is very frequent and makes easier the type definition.

## And how are sum and product represented in Scala?

The easier way to represent the type sum (also called co-product), in a paradigm with polimorphism support (in general) and in Scala (in particular), is just the inheritance feature. If we have the following case:

```sealed trait Animal
case object Cat extends Animal
case object Dog extends Animal
```

we’re indeed expressing a type co-product:

```Animal = Cat + Dog
```

that is, an `Animal` can only be, a `Cat`, or a `Dog`.

Regarding the product, we could define it as the attribute set that compounds a certain type instance. For example,

```case class Student(name: String, age: Int)
```

expressed as a product sum, would be as follows:

```Student = String * Int
```

So, for building a `Student` instance, you need a `String` and an `Int`.

If we try now to materialize the previously exposed train model (with some additives) we’ll notice that

```Wagon = String * Int
Train = Locomotive + Wagon * Train
```

is translated into Scala as

```sealed trait Train
case object Locomotive extends Train
case class Wagon(model: String, passengers: Int)
case class Nexus(wagon: Wagon, next: Train)
```

## So what is it good for?

…absolutely nothing, listen to me♩♪♫♬.
If you think, my fellow, that this is stuff that nobody uses, you haven’t thought about which `scala.Prefef` structures are defined this way. `List`s, for example, as defined as:

```trait List[+T]
case object Nil extends List[Nothing]
case class ::[T](head: T, tail: List[T]) extends List[T]
```

That is, a List can be, an empty one, or an element followed by another list.
If we express that idea in terms of products and co-products:

```List[T] = EmptyList[T] + NonEmptyList[T]
NonEmptyList[T] = T * List[T]
```

Please, notice that, the case of the empt list (`Nil`) has a bizarre but beautiful implementation in Scala.

If we try to define an empty list for eeeeeeeeeevery single existing type, we would have to instantiate a `Nil[Cat]`, a `Nil[Dog]`, …
In order to avoid this, and having an only `Nil`, we make it extend from `List[Nothing]` that, as you’ll probably remember from other posts, `Nothing` extends from eeeeeeeeevery single existing type (both primitive and programmer defined). If we add the fact of `List[T]` being covariant at `T`, we’ll have an only object `Nil` that represents the empty lists for all types. Awesome, right?

## Example: Even numbers

In order to harden to this new way of thinking, let’s suppose the following challenge: how could we represent even numbers in Scala?

### Requirements

If we’re not sophisticated enough and we trust a lil’ bit in runtime assertions, we could say that even numbers are defined as:

```case class Even(value: Int) {
require(value%2==0, "it's not even")
}
```

But, if we try to create an `Even` with an odd integer number we’ll get a giant NOPE:

```Even(1)
java.lang.IllegalArgumentException: requirement failed: it's not even
at scala.Predef\$.require(Predef.scala:233)
at Even.<init>(<console>:7)
```

However this assertion won’t be verified until run-time, the moment when `require` is executed. Thus, our code could be compiled without being correct…
We can do it much better…

### Next(Next(…))

Another option is to assume (and we won’t discuss about it) that zero is an even number, that we have infinite memory installed in our machine, that the overflow error doesn’t exist…

In that, not so far, case (…), we could define even numbers as:

```sealed abstract class Even(val value: Int)
case object Zero extends Even(0)
case class Next(previousEven: Even)
extends Even(2 + previousEven.value)
```

So, if we have a method that generate reservations for the Boat Love, that requires an even number of participants, we can use our brand new defined `Even` type:

```def loveBoatReservation(
peopleAmount: Even): Reservation = ???
```

Given there’s no way to build an `Even` from an integer that is not even, we avoid uncomfortable situations at runtime, where the amount of people that get on the Love Boat are odd. Otherwise, someone could be…

### Recursive ADTs and its techniques

Once the data type is defined, let’s suppose we want to implement the sum of even numbers:

```def sum(e1: Even, e2: Even): Even = ???
```

We handle several alternatives. One of them could be the quick-and-dirty one:

```def sum(e1: Even, e2: Even): Event =
new Even(e1.value + e2.value){}
```

But take a closer look at the fact that we’re totally ignoring the constructors we’ve defined. If we want to use pattern matching over the result:

```val four = new Even(4){}
sum(Zero, four) match {
case Zero =>
//it never gets inside this case!
case Next(Next(Zero)) =>
//OMG! IT DOESN'T FIT HERE EITHER!
}
scala.MatchError: \$anon\$1@649f2009 (of class \$anon\$1)
```

The other technique (much more sophisticated by the way) consists on invoking a recursive method that, for each call, it decreases the second even number, while it increases the first one. For doing so, we make use of `Next` apply(constructor) and unapply(extractor) methods:

```def sum(e1: Even, e2: Even): Even = {
@tailrec
def rSum(ev1: Even, ev2: Even): (Even, Even) = {
ev2 match {
case Zero => (ev1, Zero)
case Next(e) => rSum(Next(ev1), e)
}
}
val (result, _) = rSum(e1, e2)
result
}
```

Undeniably beautiful 🙂

## Conclusions

Apart from becoming a lil’ bit crazier when reading back-from-vacation posts, we can extract several main conclusions from what we’ve read:

• As we always say, every possible assertion that we can check at compile time instead of runtime, it’s saving time and headaches hunting bugs of software in production (which is more expensive and more keen to make heads roll).
• Constructors are THE key. If we define an ADT, we can control that generated values of that type are correct by defining the proper constructors: `Zero` and `Next`. In both cases, we are certainly sure that even number rules are satisfied.
• Methods that operate over recursive data types use to be recursive as well. And, apart from that, for generating values of the mentioned type (`Even ` in our example) they should only use the existing constructor methods.

In a future post, we’ll talk about the relation between data types algebra and definition of formal grammars…or not.

Peace out!

# Tipos de datos algebraicos en Scala

Qué mejor que volver de vacaciones con las pilas cargadas y con algún que otro tornillo suelto que nos empuje a escribir sobre temas que solo se te ocurren bajo el influjo de los puerros la luna.

## ¿TDA?

Un Tipo de Datos Algebraico(TDA en adelante para que no nos cobre WordPress por palabra) no es sino expresar un tipo de datos (Gato, Coche, Prevaricación) en base a un álgebra. Y cuando decimos álgebra nos referimos a sumas y productos de tipos (de Enteros, Gatos, Coches, Prevaricaciones, …). Por ejemplo:

```Train = Locomotive + Wagon * Train
```

¿Esto como se lee? Un tren puede ser: una locomotora O un vagón Y otro tren (que a su vez puede ser otro vagón y otro tren, que a su vez …).
Fijaos en la disyunción y la conjunción: la suma suele representar un OR y el producto un AND (como en el álgebra de Boole).

Es interesante también darse cuenta que, de esta definición de tipos, se puede inferir un patrón recursivo. En el caso del tren, el caso base es la locomotora y en el caso recursivo tenemos un vagón y otro tren. Como veremos más adelante, este patrón se repite y facilita la definición de tipos.

## ¿Y cómo se representa la suma y el producto en Scala?

La forma más sencilla de representar la suma (también llamada coproducto) de tipos, en un paradigma que soporte polimorfismo (en general) y en Scala (en particular), no es sino la herencia. Si tenemos el siguiente caso:

```sealed trait Animal
case object Cat extends Animal
case object Dog extends Animal
```

estamos formulando un coproducto de tipos:

```Animal = Cat + Dog
```

es decir, un `Animal` solamente puede ser, o un `Cat`, o un `Dog`.

En cuanto al producto, podríamos definirlo como el conjunto de atributos que componen una instancia de un cierto tipo. Por ejemplo,

```case class Student(name: String, age: Int)
```

expresado como suma de productos, es como sigue:

```Student = String * Int
```

Es decir, para construir el tipo `Student` hace falta un `String` y un `Int`.

Si ahora tratamos de bajar a tierra el modelo de tren antes propuesto (con algún aditivo) tendremos que

```Wagon = String * Int
Train = Locomotive + Wagon * Train
```

```sealed trait Train
case object Locomotive extends Train
case class Wagon(model: String, passengers: Int)
case class Nexus(wagon: Wagon, next: Train)
```

## ¿Y esto para qué?

Si piensas, amigo, que esto son cosas que nadie usa, es porque no te paraste a pensar en qué estructuras de `scala.predef` se definen de esta forma. Las listas (`List`) por ejemplo se definen como:

```trait List[+T]
case object Nil extends List[Nothing]
case class ::[T](head: T, tail: List[T]) extends List[T]
```

Es decir, una lista puede ser, o lista vacía, o un elemento seguido de otra lista.
Si lo expresamos en función de productos y coproductos:

```List[T] = EmptyList[T] + NonEmptyList[T]
NonEmptyList[T] = T * List[T]
```

Fijaos que el caso de la lista vacía (`Nil`) tiene una implementación muy bonita en Scala.

Si tenemos que definir una lista vacía para tooooodos los tipos existentes, tendríamos que instanciar un `Nil[Cat]`, `Nil[Dog]`, …
Para evitar eso, y tener un único `Nil`, hacemos que este extienda de `List[Nothing]` que, como recordareis de otros posts, `Nothing` extiende de tooooodos los tipos (tanto primitivos como definidos por el programador). Si a esto le sumamos que `List[T]` es covariante en `T`, tenemos un único objeto `Nil` que representa las listas vacías de tooooodos los tipos. Alucinante, ¿no?

## Ejemplo: Números pares

Para afianzar esta novedosa forma de pensar, pongámonos en la siguiente tesitura, ¿cómo podríamos representar los números pares en Scala?

### Requirements

Si somos poco delicados y confiamos más en las aserciones en tiempo de runtime, podríamos decir que los números pares son:

```case class Even(value: Int) {
require(value%2==0, "it's not even")
}
```

Si intentamos crear un `Even` con un número impar nos dirá que nope:

```Even(1)
java.lang.IllegalArgumentException: requirement failed: it's not even
at scala.Predef\$.require(Predef.scala:233)
at Even.<init>(<console>:7)
```

Sin embargo esta comprobación no se realiza hasta el momento de ejecución, que es cuando se comprueba el `require`. Por lo que nuestro código podría estar compilando pero no ser correcto…
Podemos hacerlo mejor…

### Next(Next(…))

Otra opción es asumir (y no vamos a discutir sobre ello) que el número 0 es par, que tenemos memoria infinita en nuestra máquina, que no existe el overflow, …

En ese caso, para nada alejado de la realidad (…) podríamos definir los números enteros pares como:

```sealed abstract class Even(val value: Int)
case object Zero extends Even(0)
case class Next(previousEven: Even)
extends Even(2 + previousEven.value)
```

De manera que si tenemos un método que genera una reserva para el barco del amor que requiere de un número par de participantes, podemos usar nuestro recién definido tipo `Even`:

```def loveBoatReservation(
peopleAmount: Even): Reservation = ???
```

Dado que no hay forma de construir un `Even` a partir de un entero que no sea par, evitamos situaciones en runtime en las que el número de personas que se montan en el barco sean impares. Sino siempre habría alguien …

### Mecánica de métodos sobre TDAs recursivos

Una vez definido el tipo de datos, supongamos que queremos implementar la suma de números pares:

```def sum(e1: Even, e2: Even): Even = ???
```

Tenemos varias alternativas. Una de ellas puede ser la quick-and-dirty:

```def sum(e1: Even, e2: Even): Event =
new Even(e1.value + e2.value){}
```

Pero fijaos que estamos pasando un kilo de los constructores que hemos definido. Si queremos hacer pattern matching ahora sobre el resultado:

```val four = new Even(4){}
sum(Zero, four) match {
case Zero =>
//it never gets inside this case!
case Next(Next(Zero)) =>
//OMG! IT DOESN'T FIT HERE EITHER!
}
scala.MatchError: \$anon\$1@649f2009 (of class \$anon\$1)
```

La otra técnica (algo más fina por otra parte) consiste en lanzar un método recursivo que, en cada llamada, vaya disminuyendo el segundo número par mientras que aumenta el primero. Para ello hacemos uso del constructor y extractor `Next`:

```def sum(e1: Even, e2: Even): Even = {
@tailrec
def rSum(ev1: Even, ev2: Even): (Even, Even) = {
ev2 match {
case Zero => (ev1, Zero)
case Next(e) => rSum(Next(ev1), e)
}
}
val (result, _) = rSum(e1, e2)
result
}
```

Innegablemente bello 🙂

## Conclusiones

Pues a parte de que los posts de vuelta de vacaciones suelen ser para volverse majara, saquemos varias conclusiones principales:

• Como siempre decimos, que toda comprobación que nos podamos llevar de runtime a tiempo de compilación es un ahorro de quebraderos de cabeza cazando fallos con software en producción (lo cual es caro y es más fácil que haga rodar cabezas).
• Que los constructores son la clave. Si definimos un TDA sobre los números pares, podemos controlar que los valores generados son correctos definiendo los constructores adecuados: el `Zero` y el `Next`. En ambos casos, tenemos la certeza de que se cumplen las leyes de los números enteros.
• Que los métodos que operan sobre tipos de datos recursivos suelen ser, a menudo, recursivos también. Y no solo eso, sino que para poder generar valores del tipo en cuestión (`Even ` en nuestro caso) solo deberían hacer uso de los constructores ya existentes.

En otro post hablaremos sobre la relación del álgebra de tipos y la definición de gramáticas formales…o no.

¡Agur de limón!

# Scala, Scala and nothing more

After so many posts on Scala, many snippets of code, and many weird concepts, there comes a post that had been pending since almost the beginning of this blog. What resources exist to learn Scala? Well … now we show our favorites.

Books: a good starting point 🙂

• Programming in Scala: a classic. Written by the very Odersky and with the third edition hot off the press.
• Funcional Programming in Scala (also known, in an effort of originality and simplicity, as the red book). A book that opens the mind to the functional paradigm and it is advisable not only for people who want to program in Scala, but for people who are interested in functional programming.

Courses: to deepen a bit more.

• On the online courses, Coursera and the new specialization of functional programming in Scala they have all the monopoly. It consists of 4 courses + 1 project and discusses in depth the most important aspects of Scala.
• Furthermore, scala-exercises allows us to practice in a faster way, but no less effective. Fully recommended.

Events: not only to drink beer  😉

• Scala Days : Undoubtedly the most important annual convention about Scala. Since a year, there are two conventions at year: one in America and one in Europe. In addition, all the videos of the talks are published 🙂
• Scala World: UK convention with a warm welcome and where you can hear and see some of the biggest Scala gurus.
• Scala eXchange: another of the best known conventions. It takes place on December in London.

These are the resources that we know and that we found interesting. Without doubt, there are many more that we left unsaid. If you missing some resource on this list, any contribution is welcome 🙂

# Scala, Scala, y nada más.

Después de tantos posts sobre Scala, de tantos snippets de código, y tantos conceptos rarunos, llega un post que teníamos pendiente desde casi el comienzo de este blog. ¿Qué recursos existen para profundizar en Scala? Pues bien…ahora os contamos nuestros favoritos.

Libros: un buen punto de partida 🙂

• Programming in Scala: un clásico. Escrito por el mismísimo Odersky y con la tercera edición recién sacada del horno.
• Funcional Programming in Scala (también conocido, en un afán de originalidad y sencillez, como el libro rojo ). Un libro que abre la mente al paradigma funcional y que es recomendable no solo para gente que quiera programar en Scala, sino para gente que le interese la programación funcional.

Cursos: para dar un poco más de profundidad.

• En el tema de los cursos online, Coursera y la nueva especialización de programación  funcional en Scala tienen todo el monopolio. Consta de 4 cursos + 1 proyecto y aborda en profundidad los aspectos más importantes del lenguaje.
• Por otro lado, scala-exercises nos permite practicar de una forma más rápida, pero no por eso menos eficaz. Totalmente recomendable.

Eventos: no solo para beber cerveza  😉

• Scala Days : sin duda la convención anual más importante de Scala. Desde hace un año se realizan dos convenciones, una en América y otra en Europa. Además, publican los vídeos de todas sus charlas 🙂
• Scala World: convención en UK con una gran acogida y en la que puedes escuchar y ver a algunos de los mayores gurús de Scala.
• Scala eXchange: otra de las convenciones más conocidas. Se realiza en Londres en el mes de Diciembre.

Estos son los recursos que conocemos y que nos han parecido interesante. Sin duda hay muchos más que nos dejamos en el tintero. Si echas en falta alguno en esta lista, cualquier aportación será bienvenida 🙂

# Scala: Code interpretation at runtime

With today’s post, we’ll dive into Scala code generation on the fly: at runtime. We have to be cautious of not mixing concepts with Scala macros, which generate code at compile-time. These make use of Scala type system, which is much safer than generating code at runtime.

When is it useful to make use of this mechanism then? We’ll try to shed light on this by following a very simple example, getting abstract of real implementation (that you may find at Scalera’s Github).

## The problem: “da” serializer

Let’s suppose a not-so-wild case, which consists on communicating two services via an event bus (we’ll get abstract of its implementation: it could be a message queue like Kafka, Akka streams, …).

The main idea is the following:

The producer knows how to send and the consumer has an associated callback for message arrivals:

```trait Producer{
def produce(message: Any): Try[Unit]
}
trait Consumer{
val consume: Any => Unit
}
```

Both producer and consumer services know the message types that may arrive. In our example, they could be one of these:

```case class Foo(att1: Int, att2: String)
case class Bar(att1: String)
```

If the producer wants to send a message using the event bus, it will have to serialize it somehow (JSON, Byte array, XML, …) so, by the time it reaches the opposite end, the consumer will start the inverse process (deserialization) and will get the original message.

…nothing weird so far.

If we have a JSON serializer …

```trait JsonSer[T] {
def serialize(t: T): String
def deserialize(json: String): T
}
```

and we serialize our message …

```implicit val fooSerializer: JsonSer[Foo] = ???
val foo: Foo = ???
producer.send(implicitly[JsonSer[Foo]].serialize(foo))
```

How do we know which deserializer to use when the consumer gets the message?

## Option 1: Try every possible serializer until one of them works

In our consumer, we’d have:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case message: String =>
Seq(barSerializer, fooSerializer).flatMap { ser =>
Try(ser.deserialize(message)).toOption
case bar: Bar => println("it's a bar!")
case foo: Foo => println("it's a foo!")
case _ => println("it's ... something!")
}
}
}
```

A lil’ bit coarse, right? If the proper serializer is the last of a 100 list, we would have tried and failed with 99 serializers before (Such a waste of CPU!).

Besides, we could also consider the case of having a different type deserializer, but it fits with the received message, so it would partially or wrongly deserialize the message.

## Option 2: Add the message type to the message itself

We could add an extra layer wrapping the message for indicating the message type that it contains. This way, when receiving it, we could determine the serializer type we have to use.

For writing the type, we’ll make use of Scala’s `TypeTag`s, getting info about the `T` contained message type.

```
//Wrapper for the message (and its serializer)

import scala.reflect.runtime.universe.{TypeTag, typeTag}

case class Message[T: TypeTag](content: T){
val messageType: Message.Type = typeTag[T].tpe.toString
}
object Message {

type Type = String

def typeFrom(msg: String): Message.Type = ???

implicit def messageSer[T:TypeTag:JsonSer]: JsonSer[Message[T]] = ???

}

//We'll make use of it for sending

producer.produce(messageSer[Foo].serialize(Message(foo)))

//And we redefine the consumer

lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case message: String =>
Message.typeFrom(message) match {

case "org.scalera.reflect.runtime.Bar" =>
println("it's a bar!")
val value = messageSer[Bar].deserialize(message).content
println(value.att1)

case "org.scalera.reflect.runtime.Foo" =>
val value = messageSer[Foo].deserialize(message).content
println("it's a foo!")
println(value.att2)

case _ =>
println("it's ... something!")
}
}
}
```

As you can see, we don’t have to try every possible serializer anymore. Instead of that, from the message type we’ve extracted from the Message wrapper we have added, we’re able to use the proper deserializer.

But it is also true that we have to add an extra case for each string that represents the message type. Wouldn’t it be nice to deserialize somehow and to have the defined `case` only for the already deserialized objects? (Something similar what we first tried but without trying all posible serializers). Something like:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = { msg =>
genericDeserialize(msg) match {
case f: Foo =>
case b: Bar =>
case _ =>
}
}
}
```

## Option 2-cool: Serializers ‘under the hood’

For achieving something similar, we have to get focused on that `genericDeserialize` method: Which signature should it have? Initially, something like this:

```def genericDeserialize(msg: String): Any
```

An `Any`? Seriously? My fellows, at runtime, we have no idea about the type we can get. We just know that, from a String, we’ll get ‘some….thing’. The `match` that applies to that Any will allow us to go from something totally abstract to more concrete types.

At this point is where both reflect library and Scala compiler appear.

### reflect.Toolbox

The `Toolbox` API allows parsing strings and getting the resulting AST (abstract syntax tree). From that AST, it is able to evaluate the expression and returns an instance of an Any as well.

For instantiating a Toolbox and use type references, we hace to add as SBT dependencies the following:

```libraryDependencies ++= Seq(
"org.scala-lang" % "scala-compiler" % "2.11.8",
"org.scala-lang" % "scala-reflect" % "2.11.8")
```

For example, if we wanted to parse the `"2".toInt + 4` operation,

```import scala.tools.reflect.ToolBox
import scala.reflect.runtime.{universe => ru}
import ru._

//  Scala compiler tool box
val tb = ru.runtimeMirror(

println(ru.showRaw(tb.parse("2".toInt + 4")))
```

we would get the abstract syntax tree generated as a String (by using `showRaw`):

```Apply(Select(Select(Literal(Constant("2")), TermName("toInt")), TermName("\$plus")), List(Literal(Constant(4))))
```

If we use the toolbox for evaluating the parsed expression,

```println(tb.eval(tb.parse("2".toInt + 4")))
```

we’ll get an Any that represents the resulting value of the sum:

```6
```

### “Da” serializer

Once we’ve seen how it generally works, we apply the same principle to our serializer, so the expression we’re going to try to interpret is similar to:

```{
import scala.reflect._;
import spray.json._;
import org.scalera.reflect.runtime._;
import MySprayJsonImplicits._;
import MyJsonSerImplicits._;

implicitly[JsonSer[Message[\$messageType]]]
}
```

where `MySprayJsonImplicits` and `MyJsonSerImplicits` represent the objects that contain both the Spray implicits for JsonFormat and the JsonSer implicits that we have defined before.

`\$messageType` represents the concrete type to deserialize that we would have got by using the TypeTag (as seen before).

If we adapt it to our code, we’ll get something similar to:

```object GenSer {

import scala.tools.reflect.ToolBox
import scala.reflect.runtime.{universe => ru}
import ru._

//  Scala compiler tool box

def genericDeserialize(msg: String)(serContainers: Seq[AnyRef]): Any = {

val messageType = Message.typeFrom(msg)

val serContainersImport = serContainers.map(container =>
"import " + container.toString.split("\\\$").head + "._").mkString(";\n")

val expr =
s"
|{
|  import scala.reflect._;
|  import spray.json._;
|  import org.scalera.reflect.runtime._;
|  \$serContainersImport;
|
|  implicitly[JsonSer[Message[\$messageType]]]
|}
".stripMargin

tb.eval(tb.parse(expr))
.asInstanceOf[JsonSer[Message[Any]]]
.deserialize(msg).content
}

}
```

If you take a look, we’ve empowered the generic deserialization method notation to hold a sequence of objects to import, so we won’t make explicit which object contains the Spray implicits and which one contains our `JsonSer`‘s.

```val serContainersImport = serContainers.map(container =>
"import " + container.toString.split("\\\$").head + "._").mkString(";\n")
```

It is also noteworthy that, when deserializing, we get a `Message[Any]`; so we’ll have to get the ‘content’ field that represents the raw value of Any type that holds the deserialized message.

## The result

So finally, we can now make use of our function for generically deserialize and let our consumer code be ‘swaggy’:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case msg: String =>
genericDeserialize(msg)(Seq(case3,Message)) match {
case bar: Bar => println("it's a bar!")
case foo: Foo => println("it's a foo!")
case _ => println("it's ... something!")
}
}
}
```

## Conclusions

Being able to evaluate code at runtime let us do a lot of interesting things when we want to interpret String based types. However, these kind of techniques won’t care about the so worthy and safe Scala type system, so these are tools to be used with a lil’ bit of care.

It is also kind of expensive in time terms to evaluate these expressions. I would recommend to use a type cache in this case. Something really simple like a map:

```type TypeName = String
var cache: Map[TypeName, JsonSer[Message[_]]]
```

And when invoking the method, we’ll check if the type evidence (JsonSer) we’re looking for is already stored in the map. If so, we’ll use it, otherwise, we’ll create and store it in the cache, using it as result.

Easy peasy…
Peace out!

# Scala: Interpretación de código en runtime

En el post de hoy vamos a ver cómo generar código de Scala al vuelo: en tiempo de runtime. Hemos de ser cautos de no confundirlo con las macros de Scala, las cuales generan código en tiempo de compilación. Estas últimas hacen uso del sistema de tipos de Scala, lo cual es infinitamente más seguro que generar código en tiempo de ejecución.

¿Cúando es útil hacer uso de este mecanismo entonces? Trataremos de arrojar luz siguiendo un ejemplo muy sencillo, abstrayéndonos de la verdadera implementación, la cual podéis encontrar en el Github de Scalera

Supongamos un caso (no tan descabellado) en el que queramos comunicar dos servicios vía un bus de eventos (nos abstraeremos de la implementación: podría ser una cola de mensajes tipo Kafka, un stream de Akka, …).

El punto de partida es el siguiente:

El productor sabe enviar y el consumidor tiene asociado un callback para cuando llegue un mensaje:

```trait Producer{
def produce(message: Any): Try[Unit]
}
trait Consumer{
val consume: Any => Unit
}
```

Tanto el servicio productor como el consumidor conocen los tipos de mensajes que pueden llegar, en nuestro ejemplo serán estos:

```case class Foo(att1: Int, att2: String)
case class Bar(att1: String)
```

Si el servidor quiere enviar un mensaje usando el bus de eventos, deberá serializarlo de alguna forma (JSON, array de bytes, XML, …) para que, al llegar al otro extremo, el consumidor realice el proceso inverso (deserialización) y obtenga el mensaje original.

Si tenemos un serializador para JSONs …

```trait JsonSer[T] {
def serialize(t: T): String
def deserialize(json: String): T
}
```

y serializamos nuestro mensaje…

```implicit val fooSerializer: JsonSer[Foo] = ???
val foo: Foo = ???
producer.send(implicitly[JsonSer[Foo]].serialize(foo))
```

¿Cómo sabemos qué deserializador usar cuando el consumidor reciba el mensaje?

## Opción 1: Probar con todos hasta que uno encaje

En nuestro consumidor tendríamos:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case message: String =>
Seq(barSerializer, fooSerializer).flatMap { ser =>
Try(ser.deserialize(message)).toOption
case bar: Bar => println("it's a bar!")
case foo: Foo => println("it's a foo!")
case _ => println("it's ... something!")
}
}
}
```

Un poco burdo, ¿no? Si el serializador correcto es el último de 100, estaríamos probando y fallando con 99 antes de dar con el correcto (¡qué desperdicio de CPU!).

Además, también podría darse el caso de que hubiera un deserializador para otro tipo, pero que encaja y es capaz de deserializar parcial o erróneamente el mensaje.

## Opción 2: Añadir el tipo al mensaje

Podríamos añadir una capa por encima al mensaje e indicar el tipo de mensaje que es. Así, al recibirlo, podríamos determinar el tipo de serializador que necesitamos usar.

Para escribir el tipo, nos apoyaremos en los `TypeTag` de Scala, obteniendo información sobre el tipo de mensaje contenido T.

```
//Wrapper for the message (and its serializer)

import scala.reflect.runtime.universe.{TypeTag, typeTag}

case class Message[T: TypeTag](content: T){
val messageType: Message.Type = typeTag[T].tpe.toString
}
object Message {

type Type = String

def typeFrom(msg: String): Message.Type = ???

implicit def messageSer[T:TypeTag:JsonSer]: JsonSer[Message[T]] = ???

}

//We'll make use of it for sending

producer.produce(messageSer[Foo].serialize(Message(foo)))

//And we redefine the consumer

lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case message: String =>
Message.typeFrom(message) match {

case "org.scalera.reflect.runtime.Bar" =>
println("it's a bar!")
val value = messageSer[Bar].deserialize(message).content
println(value.att1)

case "org.scalera.reflect.runtime.Foo" =>
val value = messageSer[Foo].deserialize(message).content
println("it's a foo!")
println(value.att2)

case _ =>
println("it's ... something!")
}
}
}
```

Cómo podéis ver, ya no tenemos que ir probando con todos los serializadores posibles hasta que demos con uno que funcione; sino que, a partir del tipo de mensaje (extraido del envoltorio de tipo Message que hemos añadido), somos capaces de usar el deserializador adecuado.

Pero también es cierto, que tenemos que añadir un case por cada string que representa el tipo. ¿No sería mejor poder deserializar (como sea) y que el case solo esté definido sobre los objetos ya deserializados (como antes pero sin probar a lo loco con mil serializadores)? Algo de este estilo:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = { msg =>
genericDeserialize(msg) match {
case f: Foo =>
case b: Bar =>
case _ =>
}
}
}
```

## Opción 2-guay: Serializadores ‘under the hood’

Para conseguir algo parecido, debemos de centrarnos en ese método `genericDeserialize`: ¿qué signatura debería tener? Inicialmente algo del siguiente estilo:

```def genericDeserialize(msg: String): Any
```

¿Un `Any`? ¿En serio? Amigos, en tiempo de runtime, no tenemos ni idea del tipo que nos puede llegar. Solo sabemos que, a partir de un String, vamos a obtener un ‘algo’. El `match` que se aplica sobre dicho Any nos permitirá pasar de algo totamente abstracto a tipos más concretos.

Es en este punto, donde entra en juego la librería de reflect y el compilador de scala.

### reflect.Toolbox

La api de `Toolbox` permite parsear cadenas de texto y obtener el AST (abstract syntax tree) resultante. Del mismo modo, a partir del AST es capaz de evaluar la expresión devolviendo una instancia de un tipo determinado.

Para poder instanciar un Toolbox y usar referencias a tipos, es preciso añadir como dependencias a nuestro proyecto las librerías de `scala-compiler` y `scala-reflect`:

```libraryDependencies ++= Seq(
"org.scala-lang" % "scala-compiler" % "2.11.8",
"org.scala-lang" % "scala-reflect" % "2.11.8")
```

Si por ejemplo quisiéramos parsear la operación `"2".toInt + 4`,

```import scala.tools.reflect.ToolBox
import scala.reflect.runtime.{universe => ru}
import ru._

//  Scala compiler tool box
val tb = ru.runtimeMirror(

println(ru.showRaw(tb.parse(""""2".toInt + 4""")))
```

nos devolverá el árbol sintáctico generado como un string (usando `showRaw`):

```Apply(Select(Select(Literal(Constant("2")), TermName("toInt")), TermName("\$plus")), List(Literal(Constant(4))))
```

Si a partir de la expresión parseada, usamos el toolbox para evaluarla,

```println(tb.eval(tb.parse(""""2".toInt + 4""")))
```

obtendremos un Any que representa el valor resultante de la suma:

```6
```

Una vez visto el funcionamiento general, aplicamos el mismo principio a nuestro serializador, de manera que la expresión que vamos a intentar interpretar es algo similar a:

```{
import scala.reflect._;
import spray.json._;
import org.scalera.reflect.runtime._;
import MySprayJsonImplicits._;
import MyJsonSerImplicits._;

implicitly[JsonSer[Message[\$messageType]]]
}
```

donde `MySprayJsonImplicits` y `MyJsonSerImplicits` representan los objetos que contienen tanto los implícitos de Spray para JsonFormat que hemos definido, como los implícitos de la type class JsonSer que hemos definido nosotros.

`\$messageType` representa el tipo concreto a deserializar que habremos obtenido previamente usando el TypeTag (como hemos visto antes).

Si lo adaptamos a nuestro código obtendremos algo similar a:

```object GenSer {

import scala.tools.reflect.ToolBox
import scala.reflect.runtime.{universe => ru}
import ru._

//  Scala compiler tool box

def genericDeserialize(msg: String)(serContainers: Seq[AnyRef]): Any = {

val messageType = Message.typeFrom(msg)

val serContainersImport = serContainers.map(container =>
"import " + container.toString.split("\\\$").head + "._").mkString(";\n")

val expr =
s"""
|{
|  import scala.reflect._;
|  import spray.json._;
|  import org.scalera.reflect.runtime._;
|  \$serContainersImport;
|
|  implicitly[JsonSer[Message[\$messageType]]]
|}
""".stripMargin

tb.eval(tb.parse(expr))
.asInstanceOf[JsonSer[Message[Any]]]
.deserialize(msg).content
}

}
```

Si os fijáis, hemos permitido en la notación del método de deserialización genérica, que se le pase una secuencia de objetos a importar, de manera que no se explicita qué objeto es el que contiene los implícitos de Spray y qué otro contiene los de nuestro `JsonSer`.

```val serContainersImport = serContainers.map(container =>
"import " + container.toString.split("\\\$").head + "._").mkString(";\n")
```

También cabe destacar que, al deserializar, obtenemos un Message[Any]; por lo que posteriormente hay que obtener el campo ‘content’ que representa el valor plano de tipo Any que representa el mensaje deserializado.

Ahora sí, podemos usar nuestra función para deserializar de manera genérica y dejar el código de nuestro consumidor de manera ‘reshulona’:

```lazy val consumer = new Consumer {
override val consume: Any => Unit = {
case msg: String =>
genericDeserialize(msg)(Seq(case3,Message)) match {
case bar: Bar => println("it's a bar!")
case foo: Foo => println("it's a foo!")
case _ => println("it's ... something!")
}
}
}
```

## Conclusiones

Poder interpretar código en tiempo de runtime da bastante juego cuando queremos interpretar tipos en base a String’s. Ahora bien, interpretar código en runtime se pasa por el forro el sistema de tipos que tanta seguridad aporta en Scala, por lo que son herramientas a usar con algo de cuidado.

También es algo costoso en tiempo la evaluación de estas expresiones. Os recomendaría que usarais una cache de tipos. Algo tan sencillo como un mapa:

```type TypeName = String
var cache: Map[TypeName, JsonSer[Message[_]]]
```

Y al ejecutar el método, comprobar si existe ya un JsonSer almacenado en el mapa. De ser así, usamos ese y en caso contrario, lo creamos, lo almacenamos en la caché y lo devolvemos como resultado.

Easy peasy…
¡Agur de limón!