Ya vimos hace tiempo la posibilidad de simular duck typing en C#, pero lo que seguro que alguno no sabe es que C# tiene algo más potente que el duck typing: el tipado estructural.

El tipado estructural lo mencionamos al hablar de los sistemas de tipos de otros lenguajes y es similar al duck typing en cuanto a que no hace falta declarar a priori que estamos implementando un interfaz concreto, pero además se verifica en tiempo de compilación.

Es decir, si un método necesita recibir un objeto que tenga un método void Add(int a, int b), y le pasamos un objeto que tiene ese método, aunque no hayamos indicado explícitamente que implementa un interface IAdder con ese método, nuestro código funcionará.

¿Suena bien? La verdad es que es una características muy interesante que podéis encontrar en lenguajes como scala, y aunque desgraciadamente en C# no es una características que tengamos accesible a (todo) nuestro código, el compilador sí que es capaz de hacerlo en algunos casos. No es que le podamos sacar mucho partido, pero al menos es curioso conocer estos casos.

foreach

El caso más sencillo es el de foreach. Todo el mundo sabe como funciona un foreach: nos permite recorrer cualquier objeto que implemente el interface IEnumerable o IEnumerable<T> y procesarlo elemento a elemento.

Bueno, no solo eso, porque de la época de .NET 1.0, cuando nos vestíamos con pieles de mamut y no teníamos tipos genéricos, también nos permite hacer un cast del elemento según vamos recorriendo el enumerable para simplificar un poco el código.

Lo curioso es que aquí el compilador de C# permite utilizar tipado estructural, y en realidad no es necesario que el objeto que recorremos con foreach implemente IEnumerable, basta con que el objeto tenga un método IEnumerator GetEnumerator().

Podéis probarlo con el siguiente ejemplo:

public class ImNotAnEnumerable {
  public IEnumerator GetEnumerator() {
    yield return "I'm";
	yield return "not";
	yield return "an";
	yield return "enumerable!";
  }
}

var notAnEnumerable = new ImNotAnEnumerable();
foreach (var value in notAnEnumerable) {
  Console.WriteLine(value);
}

¿Vale para algo? Seguro que existe algún motivo para esta peculiaridad del compilador de C# (y si alguien lo conoce, seguro que es Eric Lipper) pero a simple vista no parece que sea algo que podamos aprovechar mucho en nuestro código. Teniendo en cuenta que el único que puede sacar partido de esto es el foreach y que implementar IEnumerable cuando ya has implementado GetEnumerator es trivial, no se me ocurre para qué podría servir.

LINQ: from…select

El caso del foreach es bastante conocido, pero existe también otro caso parecido con la sintaxis de consultas de LINQ:

var result = from x in SomeQuery()
		     from y in OtherQuery(x)
			 select y.ToString();

Todo el mundo sabe (o debería saber) que esa sintaxis es equivalente a invocar unos cuantos extension methods sobre IEnumerable:

var result = SomeQuery()
               .SelectMany(x => OtherQuery(x))
			   .Select(y => y.ToString();

Cabría esperar que esta sintaxis sólo funcionase sobre IEnumerable, pero viendo el tema del post, ya os imagináis que no es así. Para que funcione esta sintaxis, sólo hace falta definir extenion methods para Select y SelectMany sobre la clase que queramos usar.

Vamos a ver un ejemplo (que ya os adelanto que no tiene mucho sentido) para entenderlo mejor. Suponed que tenemos una clase Box que encapsula un valor (aquí es donde los más espabilaos empezáis a pensar en monads):

class Box<A>
{
  private readonly A value;

  public Box(A value) {
    this.value = value;
  }

  public A Value {
    get { return value; }
  }
}

Y ahora supongamos (y esto ya es mucho suponer) que queremos poder escribir este código para operar con los valores encapsulados en objetos Box:

var b1 = new Box<int>(37);
var b2 = new Box<string>("El valor es {0}");

var msg = from n in b1
          from format in b2
		  select string.Format(format, n);

Console.WriteLine(msg.Value);
// >> "El valor es 37

Para que ese código compilase, podríamos hacer que Box implementase IEnumerable y su enumerador devolviese una colección con el valor encapsulado, pero eso haría que al utilizar la sintaxis de LINQ dejásemos de tener objetos Box y tuviéramos IEnumerables, por lo que no podríamos hacer msg.Value (habría que usar msg.First() o algo parecido).

Si aprovechamos el tipado estructural del que llevamos todo el rato hablando, podemos crear la siguiente clase con un par de extension methods análogos a los que existen para IEnumerable<T>, pero operando con objetos Box:

public static class BoxExtensions
{
  public static Box<B> Select<A, B>(this Box<A> box, Func<A, B> projection) {
    return SelectMany(box, _ => box, (a, b) => projection(a));
  }

  public static Box<C> SelectMany<A, B, C>(this Box<A> box, Func<A, Box<B>> function, Func<A, B, C> projection) {
    return new Box<C>(projection(box.Value, function(box.Value).Value));
  }
}

De acuerdo, es un poco feo, pero básicamente lo único que hace es implementar SelectMany como la aplicación de una proyección a los valores encapsulados en dos objetos Box y volver a empaquetar el resultado en un objeto Box. Si eres de los que antes empezó a pensar en monads, esto te sonará a bind, y si vas por esa vía la implementación queda bastante más limpia.

Con esos extension methods, y sin haber implementado ningún interface en la clase Box, el compilador ya se queda contento y podemos ejecutar el código que mostrábamos antes. Esto no sólo es aplicable a Select y SelectMany, también es válido para métodos como Join.

Al igual que en el caso del foreach, la pregunta está clara: ¿vale esto para algo? Sinceramente no lo he utilizado jamás, entre otras cosas porque no me gusta nada la sintaxis de LINQ y prefiero usar invocaciones de métodos normales. Aun así, creo que hay escenarios en los que puede dar lugar a un código bastante legible con una sintaxis similar al do notacion de Haskell o F#.

Si tuviésemos algo parecido a la maybe monad que nos explicaba Eduard Tomàs hace tiempo, y estuviésemos parseando un fichero, podríamos escribir código como éste:

Maybe<string> ReadName() {...}
Maybe<int> ReadAge() {...}

Maybe<Person> ReadPerson() {
  return from name in ReadName()
         from age in ReadAge()
         select new Person(name, age);
}

El tema de la legibilidad es cuestión de gustos y, sobre todo, de costumbres, pero este formato habrá a quién le guste.

En resumen…

Todo este post no deja de ser una excusa para ver un par de curiosidades del compilador de C# y hacer guarrerías con el código, que es lo que más nos gusta.

La utilidad real de todo esto es, como hemos visto, más que cuestionable, pero siempre es divertido conocer mejor las cosas que utilizamos todos los días.

Seguro que hay más casos como estos en los que el compilador de C# hace trampas y utiliza tipado estructural para dar soporte a algunas construcciones sintácticas, pero yo no los conozco (¿async/await tal vez?).

¿Conocéis alguno más?