IDisposable Thoughts

Honey… where is my coding t-shirt?

Hey there! Thanks for dropping by Theme Preview! Take a look around
and grab the RSS feed to stay updated. See you around!

Posts Tagged ‘c#’

Haskell, C# y Currying

Aunque el concepto de “Currying” no es algo extraño para los lenguajes funcionales (y por lo tanto bastante conocido entre usuarios de este tipo de lenguajes). No es sólo una palabra extraña sino un concepto quizás desconocido para muchos usuarios de lenguajes imperativos como C#.

Currying (llamado así en nombre de Haskell Curry) no es más que el efecto de tomar de forma individual parámetro por parámetro y procesar cada parámetro por separado en su propia función, esto lo logramos tranformando el método o función en cuestión por uno que tome uno de los parámetros y una función para luego retornar otra función. Por ejemplo, tomemos el hecho de una simple suma:

sum       :: (Int, Int) -> Int
sum (x, y) = x + y

En este caso indicamos una función llamada sum que toma dos parámetros de tipo Int y retorna un parámetro de tipo Int. Dado que las funciones son ciudadanos de primer orden en los lenguajes funcionales, podemos transformarla y definir una función que tome como uno de sus parámetros una función y retorne otra función

sum'     :: Int -> Int -> Int
sum' x y = x + y

En este caso, creamos la función sum’ que toma un parámetro tipo Int y retorna otra función que toma un parámetro tipo Int y retorna un Int. Si, ya se que a simple vista esto puede parecer extraño, pero regresemos a ver un par de puntos claves: Currying involucra evaluar uno a uno los parámetros de una función pudiendo retornar otra función en su lugar.

Bien, regresemos a la Tierra y veamos como podemos transformar este tipo de cosas en una forma más "C#". Aprovechando los métodos lambda en C# (otra adición netamente funcional) podemos describir algo como esto:

public static void Main()
{
    Func<int, int, int> sum =
        (x, y) => x + y;

    int result = sum(1,2);

    Console.WriteLine(result);
}

Pero que les parecería si cambiamos "un poco" la definición de la función sum:

public static void Main()
{
    Func<int, Func<int, int>> sum =
        x => y => x + y;

    int result = sum(1)(2);
    Console.WriteLine(result);
}

Ahora sum en vez de tomar dos enteros como parámetro y retornar un entero, ahora toma un entero retorna una función (que toma un entero y retorna otro entero) como parámetros. De esta manera sum(1) retornará otra función que luego toma el parámetro 2 y retorna 3, wow…

El concepto de currying es práctico, permite definir funciones complejas a partir de funciones mucho más simples, aunque la definición en C# parece compleja, en realidad permite definir una función a partir de simplemente un parámetro (el cual convenientemente puede permanecer dentro de la función como si fuera una constante).

public static void Main()
{
    Func<int, Func<int, int>> ntimes =
        x => y => x * y;

    var twice = ntimes(2);
    var three = ntimes(3);

    Console.WriteLine(twice(4));
    Console.WriteLine(three(4));
}

Es interesante todo lo que podríamos lograr con solamente un poco de imaginación. :)

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!

The complex way is not really the right way…

Today I was visiting a client, and I just stop and watch something that really caught my attention:

foreach (item in myList) {
    if (item.Length > 0) {
        SaveItem(item);
    }
}
// more ugly code...

Well, the code was really different (an uglier one) but you got the idea…. What I suggested to my client was a more concise solutio, create an extension method:

public static class IEnumerableExt {
    public static IEnumerable<T> ForEach(this IEnumerable<T> items, Action<T> action) {
        foreach(var item in items) {
            action(e);
        }
    }
}

The second part is the easy one…

myList
    .Where((item) => item.Length > 0)
    .ForEach((item) => SaveItem(Item));

I don’t know you, but this way looks a lot clearer to me…

Lessson learned: If your code looks complex, please, take a time and look how to make it more clearer.

Calculando la edad con un método de extensión

Algo que es bien recurrente y hasta “básico” en muchas de nuestras aplicaciones es el cálculo de la edad para una fecha dada. Tomando esto en cuenta y aprovechando a nuestros amigos los métodos de extensión me cree un par de métodos sencillos que pueden más de algún día salvarnos un par de minutos.

using System;
using Xunit;
using Xunit.Extensions;

namespace Rioshu.Educa.Facts
{
    public class DateTimeExtensionFacts
    {
        [Fact]
        public void Can_calculate_age_with_simple_dates()
        {
            var past_date = DateTime.Now.AddYears(-10);
            Assert.Equal(10, past_date.Age());
        }

        [Fact, FreezeClock(2009, 01, 01)]
        public void Can_calculate_age_with_not_so_simple_dates()
        {
            var past_date = new DateTime(2002, 02, 13);

            Assert.Equal(7, past_date.Age());
        }

        [Fact]
        public void Can_calculate_age_with_a_base_date()
        {
            var from_date = new DateTime(2010, 01, 01);
            var past_date = new DateTime(2002, 02, 13);

            Assert.Equal(8, past_date.Age(from_date));
        }
    }
}

Y aquí la implementación del helper

    public static class DateTimeExtensions
    {
        public static int Age(this DateTime date)
        {
            return Age(date, DateTime.Now);
        }

        public static int Age(this DateTime date, DateTime from_date)
        {
            if (from_date.Month <= date.Month && from_date.Day < date.Day) {
                return from_date.Year - date.Year - 1;
            }

            return from_date.Year - date.Year;
        }
    }

Como siempre acepto sugerencias y comentarios :) Hasta la próxima!

Un amigo necesitaba algo para recorrer una lista de links y ver si estos existian o no, como necesitaba la .Net framework decidí ayudarle y crearle un simple Extension Method que podría hacerle la vida más fácil que revisar link por link manualmente si la página existía, aquí los dejo con el código:

using System;
using Xunit;

namespace ClassLibrary2
{
    public class BrokenLinkFacts
    {
        [Fact]
        public void IsBrokenMustReturnFalse()
        {
            var url = new Uri(@"http://www.google.com");
            Assert.False(url.IsBroken());
        }

        [Fact]
        public void IsBrokenMustReturnTrue()
        {
            var url = new Uri("http://www.rioshu.com/does_not_exist");
            Assert.True(url.IsBroken());
        }

        [Fact]
        public void IsBrokenStringMustReturnFalse()
        {
            const string url = @"http://www.google.com";
            Assert.False(url.IsBroken());
        }

        [Fact]
        public void IsBrokenStringMustReturnTrue()
        {
            const string url = @"http://www.rioshu.com/does_not_exist";
            Assert.True(url.IsBroken());
        }
    }
}
using System;
using System.Net;

namespace ClassLibrary2
{
    public static class UrlExtension
    {
        public static bool IsBroken(this Uri uri)
        {
            var web_client = WebRequest.Create(uri);
            web_client.Timeout = 2000;

            try {
                web_client.GetResponse();
            } catch (WebException exception) {
                return true;
            }

            return false;
        }

        public static bool IsBroken(this string uri_string)
        {
            var uri = new Uri(uri_string);
            return IsBroken(uri);
        }
    }
}

Creando el mapping de una legacy DB en la oficina, me topé con el mapping de herencia de NHibernate (muy efectivo por cierto). Aunque ya he mapeado herencia anteriormente en NHibernate, algo que irrita de sobremanera es el archivo gigante que se crea ante la clase base. Revisando la documentación de NHibernate me topo con el concepto de mapas modulares para clases de herencia, algo que nos resuelve los dolores de cabeza con mapeos de herencia muy grandes :D

Tomemos por ejemplo este mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="Sample"
                   namespace="Sample">
  <class name="Member" table="members">
    <id name="Username" column="username">
      <generator class="assigned" />
    </id>
    <discriminator column="type" type="Int32" />
    <property name="FirstName" column="first_name" not-null="true" />
    <property name="LastName" column="last_name" not-null="true" />
    <property name="Email" column="email" not-null="true" />
    <property name="BirthDate" column="birthdate" not-null="true" />
    <joined-subclass table="students" name="Student">
      <key column="student_id" />
            <property name="Added" />
    </joined-subclass>
  </class>
</hibernate-mapping>

(Para comprender un poco más de herencia en nhibernate usando joined-subclass recomiendohttp://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/inheritance.html en la documentación de NHibernate).

Bien, lo feo es que si he de mapear 5 clases heredadas debo agregar cada joined-subclass en el mismo archivo y eso me crearía archivos de mapeo poco portables y de díficil mantenimiento. Es cuando llega a salvar los archivos de mapeo modular.

En el caso anterior movemos la declaración de joined-subclass de Student a su propio archivo hbm y solo variamos agregandole el atributo “extends” indicando que clase (definida en su propio hbm) extendemos.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="Sample"
                   namespace="Sample">
  <joined-subclass table="students" name="Student"
                   extends="Member">
    <key column="student_id" />
    <property name="Added" />
  </joined-subclass>
</hibernate-mapping>

Sencillo no?

Otro día hablaremos un poco más de nuestro siempre versátil NHibernate ;)

Es común en aplicaciones web trabajar con imágenes y hacer una que otra simple operación (cambiar el tamaño de una imagen, cambiar el formato de una imagen, obtener el MimeType de una imagen, cosas como esas).

Como duplicar código es lo peor que uno puede hacer, aproveché la simempre útili ayuda de los Extension Methods para estas simples operaciones, se los comparto a todos :D

using System;
using System.Drawing;
using System.Drawing.Imaging;
using System.IO;

namespace Rioshu.Utils.Drawing
{
    public static class ImageExtensions
    {
        public static Image ToSize(this Image image, int width, int height)
        {
            var resized_image = new Bitmap(width, height);
            using (var graphics = Graphics.FromImage(resized_image)) {
                graphics.DrawImage(image, 0, 0, width, height);
            }

            return resized_image;
        }

        public static Image ToSize(this Image image, int size)
        {
            var max_side = image.Width > image.Height ? image.Width : image.Height;
            var factor = (float) size/max_side;

            var new_width = Convert.ToInt32(factor*image.Width);
            var new_height = Convert.ToInt32(factor*image.Height);

            return ToSize(image, new_width, new_height);
        }

        public static Image ToFormat(this Image image, ImageFormat format)
        {
            var memory_stream = new MemoryStream();
            image.Save(memory_stream, format);

            return new Bitmap(memory_stream);
        }

        public static byte[] GetBytes(this Image image)
        {
            var memory_stream = new MemoryStream();
            image.Save(memory_stream, image.RawFormat);
            var content = new byte[memory_stream.Length];
            memory_stream.Seek(0, SeekOrigin.Begin);
            memory_stream.Read(content, 0, content.Length);

            return content;
        }

        public static string GetMimeType(this Image image)
        {
            foreach (var codecInfo in ImageCodecInfo.GetImageDecoders()) {
                if (codecInfo.FormatID == image.RawFormat.Guid) {
                    return codecInfo.MimeType;
                }
            }
            return "image/unknown";
        }
    }
}

La forma de usarlos es sumamente fácil, basta con un simple ejemplo:

// digamos que leemos un archivo o stream que contiene una imagen
var image = Image.FromStream(file_stream).ToSize(125, 125);
// Resto de las operaciones de imagen

Espero le sea de ayuda a mas de alguien. Saludos!

Usings y Object Initializers == Problemas!

Revisando mis links diarios me topo con esta noticia del famoso Ayende (alias de Oren Eini) acerca del uso de Objects Initializers en using statements, explico un poco de que se trata:

Como ustedes recuerdan, objetos que obedecen a la Dispose Pattern, como por ejemplo los DataReaders en ADO.net, mantienen un patron de “destrucción” con instrucciones de liberación de recursos o instrucciones de destrucción del objeto, en otras palabras, que hacer cuando el objeto ya no es necesario (no implica que deterministicamente destruimos al objeto, eso es otrotema):

// Hacemos lo que queremos con el objeto repository
var repositorio = new UserRepository();
repositorio.Dispose();

Bien, de igual manera el compilador de C# 3.0 nos ofrece la opción de inicializadores de objeto, imaginemos que el objeto repositorio pueda tener un parámetro opcional con la información del “nombre” del repositorio (nuevamente un ejemplo silly):

// forma C# 2.0
var repositorio = new UserRepository();
repositorio.Name = "Mi repo";

// forma C# 3.0 con object initializers
var repositorio = new UserRepository() { Name = "Mi repo" };

Internamente el compilador agrega la siguiente línea con un setter a la propiedad, interesante no?.

Bien, como recordaran, la Disposable Pattern es tan común que hay una forma de “resumirla” o un shortcut en la framework:

using (var repositorio = new UserRepository()) {
    // Hago lo que quiera con el objeto
}

Si el objeto generara una excepción DENTRO del bloque de igual manera se correría Dispose, eso hace más segura nuestra implementación.

Bien, que tal si mezclamos ambas?:

using (var repo = new UserRepository() { Name = SimpleClass.GetName() }) {
// Blah
}
// PROBLEMA!!! lo "equivalente" generado
var repo = new UserRepository();
repo.Name = SimpleClass.GetName();
using (repo) {
// Blah
}

Aunque mi ejemplo es realmente trivial y hasta “tonto” podemos observar claramente el problema, si el inicializador “repo.Name = ’blah’” fallara, NUNCA entraríamos al using, por lo tanto no se correría Dispose(), o sea, que recursos no se liberarían como nosotros esperaramos.

Tengo entendido que esto es “by design” (realmente no se porqué), y que el compilador de Mono (el MCS) lo genera de la manera “ideal”. Esperemos que para C# 4.0 compiler esto sea resuelto, mientras tanto, eviten object initializers en declaraciones de sentencias using.

Hasta la próxima!

UPDATE:

Para contestar uno de los comentarios: si, si definimos tu "conexión" de la manera:

using (var con = new SqlConnection() { MyProperty = int.Parse("error") }) {
// Buh! nunca entro aqui! (ni corro dispose!)
}

En ese caso se genera una instancia con nombre "impronunciable" y se usa el setter, para luego entrar al bloque using. Eso involucra que cuando falle el setter de la propiedad tu objeto nunca entrará al bloque using, para evitar eso deberiamos cambiar el código para que luzca algo asi:

using(var con = new SqlConnection()) {
    con.MyProperty = int.Parse("error");
}

La última sentencia funcionará como esperamos, se creará una excepción, pero debido a que la excepción se generó dentro del bloque se correrá exitosamente el Dispose del objeto SqlConnection.