Tag Archive for functional programming

Generating generic delegates with expression trees

A few weeks ago I was working in a patch for an awesome mocking meta framework named mfakes, a very awesome mocking meta-framework based in the spicy Machine Specification BDD testing framework, go, try it, you are going to love it!.

Well, one of the awesome points in mfakes it’s to abstract mocking frameworks, so mfakes provides adapters for popular mocking frameworks like Rhino Mocks, Moq, NSubstitute and FakeItEasy. So instead of thinking which one to use, just concentrate in the test. Simple.

Anyway, there was a feature lacking in mfakes, and as every developer when something it’s lacking a feature you just go ahead and implement it, nothing beats open source. The interesting point was trying to “wrap” different way to interact between every mocking framework, everyone has a different way to see the world, it’s not bad, but it’s different. I found a very interesting problem with FakeItEasy and constructor parameters in a Mock.

In most mocking frameworks there’s an easy way to specify constructor parameters for a mock, in Moq, for example, you just do something like this:

var foo = new Mock<T>("foo", "bar");

// Generate this it's easy, it's just a simple generic type
// with a parameter list

public object CreateFake(Type interfaceType, params object[] args) {
    var closedMockType = typeof(Mock<>).MakeGenericType(interfaceType);
    var objectProperty = closedMockType.GetProperty("Object", closedMockType);
    var instance = (args != null && args.Length > 0)
        ? Activator.CreateInstance(closedMockType, args) : Activator.CreateInstance(closedMockType);
    return objectProperty.GetValue(instance, null);
}

The problem it’s that FakeItEasy it’s magic, and uses a very nice strong typed way to do it

var foo = A.Fake<FooClass>(x =>
    x.WithArgumentsForConstructor(
        new[] object {"foo", "bar"}));
// Another way to do it, more strongly-typed
var foo = A.Fake<FooClass>(x =>
    x.WithArgumentsForConstructor(
        ()=> new FooClass("foo", "bar")));

Well, if you think about that, there’s not a simple way to abstract a non-generic, non-typed expression with a generic, strong-typed, functional expression, well, not a simple way to do it at least you use the expressiveness of binary expression trees. How do we abstract this? well, let’s see the simple expression:

Now, let’s create a function to return that expression based in parameters, let’s abstract everything with the only knowlege of the type and the parameters:

// Transforming this:
var foo = A.Fake<T>(Action<IFakeOptionsBuilder<T>> opts)

// Implies something like this
public static Delegate CreateForType(Type type, object[] args) {
    var optType = typeof(IFakeOptionsBuilder<>).MakeGenericType(new[] { type });
    var actType = typeof(Action<>).MakeGenericType(new[] { optType });

// Now we have the type for the action and the options builder
// Let's use it to create an expression tree!

    var r = Expression.Parameter(optType, "r");
    var method = optType.GetMethod("WithArgumentsForConstructor", new[] { typeof(IEnumerable<object>) });
    var p = Expression.Constant(ctorArgs);
    var call = Expression.Call(r, method, p);
    var lambda = Expression.Lambda(actType, call, new[] { r });
    var exp = lambda.Compile();
}

And well, now that we have the function to call (we generated it), it’s time to create the fake

public object CreateFake(Type type, params object[] args) {
    var closedFakeType = typeof(Fake<>).MakeGenericType(interfaceType);
    var objectProperty = closedFakeType.GetProperty("FakedObject", interfaceType);

    var options = args != null && args.Length > 0
        ? FakeItEasyHelper.CreateForType(interfaceType, args) : null;

    var instance = args != null && args.Length > 0
        ? Activator.CreateInstance(closedFakeType, new object[] {options})
        : Activator.CreateInstance(closedFakeType);

    return objectProperty.GetValue(instance, null);
}

See? that’s the reason because Functional programming it’s so awesome, functions are just another variable, you can generate them, use them, modify them, use them. Next time you have a problem try to think in a functional way, you will see how awesome is!.

More about Expression Trees in the amazing book C# in Depth, Second Edition by John Skeet or go and pick a functional language (like this Programming F#), study it, enjoy it, use it in your favourite non-functional language.

Happy coding!

NOTE: the patch it’s already included in mfakes, no worries!

Lenguajes funcionales, divide y vencerás

Hace unos días me encontraba en una sesión de review de código en la oficina de un cliente y me topé con el típico problema recurrente del cual creo que ya muchos estamos empapados: “La clase superhéroe”, si, esa amiga que no sólo se conecta a la base de datos, sino que también crea la consulta, chequea los datos, genera el id aleatorio del usuario y también al mismo tiempo inserta y cambia los registros en la base de datos, todo en una “compacta” clase que hace literalmente todo.

No, este post no es acerca de SRP (Single Responsability Principle) o de principios de diseño y pensamiento en objetos ni tampoco se trata de la vieja escuela de “modularización” usando subrutinas (me imagino que alguien recuerda sus viejas lecturas de hace muchos años cuando aprendían algo como Pascal o BASIC). En vez de eso, decidí conversar un poco de lo que he aprendido mientras continuo mi jornada de aprendizaje en lenguajes funcionales (usando Haskell).

Advertencia: Estoy en el proceso de aprendizaje de lenguajes funcionales y Haskell, es muy probable que lo que exprese o diga en este post realmente sean producto de mi alta taza de ignorancia al respecto. :D

En Haskell las funciones son ciudadanos de primer orden, son uno más, de hecho, son sumamente importantes (me imagino que en los demás lenguajes funcionales el principio es el mismo). El principio que rige o elimina la duplicidad y la reutilización de operaciones en lenguajes funcionales es la simple composición de funciones, o sea, de forma similar a como deberíamos desarrollar aplicaciones mediante composición de objetos, en un lenguaje funcional, funciones complejas se crean mediante funciones más simples, primitivas y sencillas. Lección a aprender, procura que tu “método” o “función” (o como quieras llamarlo, si quieres, hasta “subrutina” le puedes poner) haga una y sólo una cosa.

Tomemos el siguiente ejemplo (tomado del libro Programming in Haskell de Graham Hutton) dónde definimos un cifrador de cesar usando simples funciones en Haskell (probablemente se puede definir en una forma mucho más óptima, pero que se yo!)

import Data.Char

{-
- Caesar cypher definition
-}

-- Transform a char to its numeric representation
let2int  :: Char -> Int
let2int a = ord a - ord 'a'

-- Transform an integer to a char representation
int2let  :: Int -> Char
int2let a = chr (ord 'a' + a)

-- Shift a character by its factor
shift    :: Int -> Char -> Char
shift n a | isLower a = int2let z
          | otherwise = a
    where
        x = let2int a
        y = x + n
        z = y `mod` 26 -- because we can reach z someday!

-- Now it is time to encrypt!
encode      :: Int -> String -> String
encode n xs = [shift n x | x <- xs]

La forma en que funciona es simple, al final esta declarada la función encode que utiliza a su vez list comprehension (hablaré de esto después) y a la función definida shif, que a su vez utiliza la función let2int e int2let que también usan a la función incluída ord (que existe en el space Data.Char).

Quizás todo esto se pueda ver “trivial” pero es muy común ver métodos o “Modules” con métodos en Visual Basic que literalmente hacen todo: piden la entrada a la pantalla al usuario, verifican que la entrada sea la correcta, luego hacen el calculo y por último le muestran al usuario el resultado, si, todo en el mismo Main del módulo…

Creo que debemos comenzar a aprender un poco más de lenguajes simples como los lenguajes funcionales, sin construcciones exóticas, sin extensiones mágicas… simples composiciones, simple reutilización, donde la simpleza es el motivo. Claro, esto no implica que no podemos hacer cosas “complejas” en un lenguaje funcional, por ejemplo, Darcs (un sistema de control de versiones distribuido) y Leksah (un IDE para Haskell) se encuentran ambos hechos en Haskell.

La próxima vez que se topen con un super gordo método main, recuerden que es mejor ponerlo a dieta, aprendan de Haskell :D

¡Saludos!

NOTA: mi amigo José Romaniello me comenta que el patrón o el “antipatrón” de la clase superhéroe se conoce como “God Class”, aunque yo prefiero el nombre de superhéroe :D

C# y el caracter Wildcard de Haskell

Escuchando al Dr. Meijer en su serie Functional Programming with Haskell, me topé con algo interesante: el caracter wildcard de Haskell. El "wildcard” (_) en Haskell es prácticamente lo mismo que el caracter wildcard (*) en nuestros sistemas operativos, evalúa o implica cualquier “otra cosa”. Por ejemplo:

(&&)         :: Bool -> Bool -> Bool
True && True = True
_ && _       = False

Tiene una interpretación sumamente sencilla: “Dada una función llamada &&, que toma un Bool y retorna una función que toma un Bool y retorna un Bool siendo sus parámetros True y True retornará True, de cualquier otra manera, retornará False”. A simple vista pensaremos que en lenguajes de “diario” no existen conceptos como el de “wildcard”, pero como lo dice luego el Dr. Meijer, en C# si tenemos el concepto de wildcard, claro, con nuestros amigos los Generics (otro concepto tomado de lenguajes funcionales y que data de muchos años atrás :P ).

En C# el guión bajo es un nombre aceptado de una variable, así que podemos utilizarlo como caracter de wildcard (a lo Haskell), imaginemos la declaración desiguiente tipo genérico:

public interface IRepository<T> {
    T GetById(int id);
}

Bien, que tal si lo nombramos algo así:

public interface IRepository<_> {
    _ GetById(int id);
}

Debo admitir que en mi caso lo veo algo extraño para los tipos de retorno… Que tal si usamos un wildcard para aquellos tipos que "debemos" definir pero que no "vamos" a utilizar.

// Siendo esta la declaración de un evento
runtime.RuntimeStarted += (sender, e) => Console.WriteLine(e.InstanceId);

// De igual manera, sender es un Object el cual no utilizamos
runtime.RuntimeStarted += (_, e) => Console.WriteLine(e.InstanceId);

Si, ya se que más de algún usuario de VB.NET me comentará que en VB9 no es necesario declarar en los eventos aquellos parámetros que no utilizaremos, pero esa es harina de otro costal.

Al parecer si hay un par de cosas que un usuario de C# puede aprender de Haskell… Saludos!

Haskell y los lenguajes funcionales

programming haskell Soy fiel creyente que todo _buen_ desarrollador debe aprender por lo menos dos lenguajes nuevos por año, algunas otras personas diferiran conmigo y esgrimiran el dicho “es que hay que ser bueno y realmente bueno en una sola cosa”, y no estoy para discutir eso (para dejarlo claro, no creo que deba ser así, pero ese es otro tema).

Creo firmemente que aprender un lenguaje NO se trata de aprender sus palabras claves, ni sus librerias (aunque ciertamente podemos aprender mucho de ellas) o incluso, creer que porque hacemos el “hola mundo” ya conocemos de que se trata, gran error a mi parecer. Aprender un lenguaje lleva consigo aprender su “razón de ser”, enteder el problema que resuelve, comprender el porqué fue hecho, y si es posible, acoplar o absorver las buenas cosas que su paradigma comprende en nuestro lenguaje “de diario” que puedan ayudarnos y hacernos mejores desarrolladores.

En estas últimas semanas me decidí a tratar de comprender un poco acerca de lenguajes funcionales (algunos habran escuchado F#, ese es un ejemplo de un lenguaje funcional en la .Net Framework, Scala es otro en la Java VM) y como lenguaje modelo decidí aprender con Haskell, un lenguaje diseñado para la enseñanza de lenguajes funcionales, de esta manera aprovechaba una excelente colección de videos acerca de Functional Programming with Haskell a cargo del Dr. Erik Meijer (un señor sumamente inteligente y chistoso si me preguntan) los cuales estan disponibles para bajar del sitio de Channel 9, junto con las diapositivas y ejercicios de ejemplo, claro, deben acompañar la lecture con el libro de Programming in Haskell de Graham Hutton (de hecho las lecciones del Dr. Meijer estan basadas en el libro y estan diseñadas para darle seguimiento a cada uno de los capítulos del libro. Concejo, consigan el libro).

Me parece sumamente interesante el comienzo del libro y de las lecciones del Dr. Meijer. Soy fanático de la historia y comenzar una lecture con “historia de los lenguajes funcionales” me pareció impresionante, quizás exagero, pero creo que si los cursos universitarios incluyeran un “historia del arte de las ciencias de la computación” crearíamos profesionales un poco más concientes de que rayos se trata el oficio de computer sciences (o computer engineering, como prefieran), bueno, quizás ya estoy divagando un poco… Es increíble cosas que damos como “recientes” o “nuevas” realmente fueron ideadas por mentes sumamente billantes hace ya muchos años. Cosas como los Domain Specific Languages (DSL) y características ya más que conocidas como type inference y lazy evaluation datan desde los años 70. Quizás si vemos la historia nos daremos cuenta de qué es lo siguiente a venir en los próximos años.

Ahí les contaré que tal me va con Haskell. Hasta el próximo post!