Variable not found en Geeks.ms : vs2008

Error al conectarse al administrador de deshacer del archivo de código fuente

José M. Aguilar — Mon, 22 Feb 2010 09:12:00 GMT

“Error al conectarse al administrador de deshacer del archivo de código fuente c:\blahblah\archivo.designer.cs” es un mensaje con el que Visual Studio (tanto la versión 2005 como 2008) me ha abofeteado en numerosas ocasiones cuando estoy desarrollando sitios web ASP.NET. Y la verdad, es uno de esos casos en los que no sabes qué hacer: recompilas, limpias la solución, abres y cierras el IDE… pero nada, cuando le da por ahí, no hay forma de hacerlo...(read more)

Compilar las vistas en ASP.NET MVC

José M. Aguilar — Wed, 03 Jun 2009 21:04:00 GMT

El código introducido en las vistas ASP.NET MVC pueden ser fuente de problemas en tiempo de ejecución debido a que, por defecto, no se compilan con el proyecto, sino cuando el sistema necesita mostrarlas por primera vez. Es decir, es perfectamente posible que errores de codificación en un archivo .ASPX no sean detectados hasta el momento de su ejecución, provocando un YSOD de los de toda la vida.

Un ejemplo. Imaginemos una vista tipada (en un archivo .ASPX) en la que hemos incluido el siguiente código, perfectamente válido…

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
         Inherits="System.Web.Mvc.ViewPage<Persona>" %>
[...]
<h2>Datos personales</h2>
Nombre: <%= this.Model.Nombre %>

[...]

… perfectamente válido mientras la clase Persona tenga una propiedad que se llame Nombre. Si eliminamos esta propiedad o simplemente cambiamos su nombre, la refactorización automática del IDE no se realizará sobre el código de la vista, y se generará un error en ejecución en cuanto intentemos acceder a ella, es decir, estaremos llevando a tiempo de ejecución problemas propios del tiempo de compilación.

Afortunadamente, ASP.NET MVC framework incluye un mecanismo que nos permite forzar la compilación de las vistas y, así, detectar estos problemas de forma temprana, antes de poner el sitio en producción.

Para activarlo, lo primero que hay que hacer es abrir el archivo del proyecto (.csproj o .vbproj) con cualquier editor de textos, como el block de notas, localizar en las primeras líneas el comienzo de la sección PropertyGroup, e insertar justo después la declaración que habilita la compilación de las vistas:

<PropertyGroup>
   <MvcBuildViews>true</MvcBuildViews>
   [...]
</PropertyGroup>

Ojo a un detalle: es posible que en algún punto del archivo del proyecto exista una declaración que anule la anterior así: <MvcBuildViews>false</MvcBuildViews>. Debéis eliminar esa línea, pues de lo contrario no se activará esta característica.

Acto seguido, debemos asegurarnos de que exista el siguiente código cerca del final del archivo; en mi caso ya existía, pero si no es así debemos insertarlo, por ejemplo, justo antes del cierre del documento (en la línea anterior a </Projects>).

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
   <AspNetCompiler VirtualPath="temp" 
                   PhysicalPath="$(ProjectDir)\..\$(ProjectName)" /> 
</Target>

Una vez guardado el archivo, recargamos la solución en Visual Studio, y listo. Eso sí, a partir de este momento tendremos que esperar un poco más durante la generación del proyecto, pero la seguridad que aporta bien vale la pena.

Fuente: Compile Views in ASP.NET MVC - Stack Overflow

Publicado en: Variable not found.

Plantillas de proyectos ASP.NET MVC 1.0 para NUnit

José M. Aguilar — Mon, 18 May 2009 21:27:00 GMT

Joe Cartano, perteneciente al Visual Web Development Team de Microsoft, ha publicado en el blog oficial (Visual Web Developer Team Blog) un post anunciando que ha actualizado la plantilla que permite crear directamente proyectos ASP.NET MVC con tests unitarios NUnit.

Así, una vez instalado, al crear un proyecto de tipo ASP.NET MVC nos aparecerá un cuadro de diálogo como el siguiente, en el que se nos brindará la oportunidad de crear en la solución un proyecto de pruebas unitarias utilizando NUnit:

Para los poseedores de algunas de las versiones profesionales de Visual Studio 2008, esta ventana no es nueva, puesto que por defecto ya se incluyen los proyectos de tests propios de Microsoft, pero sí lo es para la versión express del IDE, que no incluye el framework de pruebas y en el que había que crear el proyecto a mano.

El proyecto, que se crea automáticamente, realiza 27 tests sobre la plantilla original de proyectos ASP.NET MVC, y pueden servir como base para seguir creando nuestro propio conjunto de pruebas:

La plantilla se instala descargando el archivo .zip cuyo enlace encontraréis en el post original y ejecutando, si es necesario con un usuario con privilegios de administrador, el script installNUnit.cmd disponible en el raíz del directorio donde lo hayáis descomprimido.

Para que todo vaya bien, debéis contar con NUnit previamente instalado en vuestro equipo. Pero ojo, las plantillas están preparadas para la versión 2.4.8.0 y la versión actual es la 2.5.0.9122, por lo que puede que no os funcionen bien si estáis a la última.

En este caso, es necesario tocar a mano los archivos de plantillas. Podéis seguir estos pasos:

Descargad el archivo de plantillas desde el blog del Visual Web Developer Team .
Descomprimidlo sobre cualquier carpeta.
En los subdirectorios CSharp y Visual Basic encontraréis un archivo llamado MvcApplication.NUnit.Tests.zip. Son las plantillas para cada uno de esos lenguajes.
El interior de dicho zip está el archivo de proyecto (MvcApplication.NUnit.Test.vbproj en el caso de Visual Basic, MvcApplication.NUnit.Test.csproj en C#). Descomprimid sólo estos archivos y buscar en ambos la cadena “2.4.8.0” y sustituirla por la versión de NUnit que tengáis instalada (en mi caso, “2.5.0.9122”). Al acabar, actualizad de nuevo el .zip con el archivo que acabáis de editar.
Ejecutad el script de instalación installNUnit.cmd.

Crossposteando desde: Variable not found.

C#: Desmitificando las expresiones lambda (y III)

José M. Aguilar — Tue, 28 Apr 2009 21:40:00 GMT

En el primer post intentamos describir qué eran las expresiones lambda, resumiendo muy brevemente su utilidad, así como los aspectos sintácticos de este tipo de construcciones del lenguaje. El segundo lo enfocamos a explicar el papel de las lambda como funciones anónimas, su estrecha relación con los delegados, y su forma de utilización.

En esta tercera y última entrega de la serie, vamos a centrarnos en otra de las grandes utilidades de las expresiones lambda en .NET framework: la definición de árboles de expresión.

Las lambda como árboles de expresión

Los compiladores de C# y VB.NET pueden, bajo determinadas circunstancias, utilizar las lambdas para crear un árbol de expresión, una estructura en memoria que representa en forma de árbol las operaciones a realizar, y en el orden que hay que hacerlo, para lograr un objetivo. Si lo queréis ver más claro, observad el diagrama adjunto, en el que se muestra el árbol de expresión correspondiente a una función lambda que obtiene la media de dos números.

Esto es muy diferente al caso anterior, donde hablábamos de las lambda como funciones ejecutables que podían ser referenciadas por delegados e invocadas de forma directa. Entonces las expresiones lambda eran transformadas en tiempo de compilación en código ejecutable (de hecho, en métodos estáticos que pueden ser consultados usando Reflector u otros desensambladores), y por ello podíamos utilizarlas de forma directa.

En el caso de los árboles de expresión, la compilación no genera código ejecutable correspondiente a las instrucciones definidas en la lambda, sino el código para crear y llenar el árbol con dicha expresión. Después, en tiempo de ejecución, será posible recorrer dicho árbol, analizarlo, seriarlo para almacenarlo o moverlo a otras capas, e incluso compilarlo para poder lanzar su ejecución.

Pero paremos aquí un momento... según lo dicho, cuando el compilador se encuentra con una expresión lambda, por ejemplo x => x * 2, puede optar por generar una función anónima o por generar el código de llenado del árbol, ¿cómo sabe lo que debe hacer?

Pues bien, el compilador elegirá la opción adecuada dependiendo del tipo de la referencia a la expresión lambda. Si se trata de un tipo de delegado como Func o Action, generará código ejecutable y las referencias a la función serán tratados como delegados; si se usa el tipo Expression, que veremos más adelante, se generará el árbol de expresión y las referencias no se considerarán delegados, sino objetos de este tipo. Por este motivo no podemos utilizar para declarar lambdas variables locales de tipo implícito: el compilador no sabría qué hacer.


  var dobla = a => a * 2; // Error: no se puede asignar
                          // una expresión lambda a una variable
                          // local de tipo implícito.

Definición de árboles con expresiones lambda

Para definir un árbol de expresión a partir de una lambda debemos utilizar el tipo genérico Expression<TipoDelegado>, siendo TipoDelegado un delegado como Action o Func de los descritos en el post anterior. ¿Que esto os parece confuso? Pues esperad a ver el ejemplo... ;-)

  Expression<Func<int, int, int>> media = (a, b) => (a + b) / 2;

En realidad, aparte de lo difícil de leer que es una declaración de este tipo, la idea es bastante sencilla. Lo que estamos indicando al compilador es que queremos montar un árbol de una expresión de la que conocemos el tipo de los parámetros de entrada y del valor de retorno, datos que indicamos mediante el delegado que utilizamos como argumento genérico de la clase Expression, la porción que he marcado de amarillo en el ejemplo anterior. Además, este delegado lo utilizaremos cuando queramos convertir el árbol de expresión en código ejecutable, más adelante veremos cómo.

Para que quede claro, ahí van algunos ejemplos más:

  // Árbol de expresión de una función que determina
  // si el parámetro que le llega es par
  Expression<Func<int, bool>> esPar = a => a%2==0;

  // Árbol de expresión de una función 
  // que retorna el máximo de dos números.
  Expression<Func<int, int, int>> maximo =
              (a, b) => a > b ? a:b;

  // Árbol de expresión de una función que
  // retorna un string transformado
  Expression<Func<string, string>> TrimMays = 
              a => a.Trim().ToUpper();

  // Árbol de expresión de una acción 
  // sin parámetros que escribe por consola la fecha y hora.
  Expression<Action> accion =
              () => Console.WriteLine(DateTime.Now);

Fijaos que el tipo de delegado Action o Func, que son los parámetros genéricos de la expresión, son los que definen los tipos de parámetros y retornos de la lambda. En el primer caso, el Func<int, bool> define que la función recibe un entero y retorna un booleano; en el último caso, ni se envía ni se recibe nada, de ahí que utilicemos un delegado Action.

Un detalle importante, antes de que se me olvide comentarlo. Los árboles de expresión sirven, como su nombre indica, para almacenar expresiones. Esto limita el tipo de construcciones de código que podemos usar en las lambdas que los definen: no está permitido utilizar asignaciones, bloques con llaves { }, ni bucles... debe tratarse de una expresión que pueda representarse en una jerarquía de árbol. Si intentamos saltarnos estas restricciones, el compilador generará un error, aunque el tipo de delegado sea correcto y la función lambda también, como en el siguiente ejemplo:

  // Suma los n primeros naturales
  Expression<Func<int, int>> expr =
    n => {
           int t = 0;
           for (int i = 1; i <= n; t += i++) ;
           return t;
         };

  // Error CS0834: Una expresión lambda con cuerpo no puede ser 
  // convertida a árbol de expresión

Volvemos un poco atrás ahora para recordar cuando comentaba que la compilación de una lambda no genera código ejecutable correspondiente a las instrucciones definidas en la expresión, sino el código para llenar el árbol de expresión que la representa.

¿Y cómo hace eso? Muy sencillo. El compilador analiza la expresión, genera la secuencia de instrucciones que compone el árbol, las compila, e introduce el resultado en el ensamblado. El siguiente ejemplo muestra cómo crear un árbol de expresión usando una lambda, y una aproximación al código equivalente que genera el compilador, para que nos podamos hacer una idea del trabajo que nos ahorra esta característica del lenguaje:


  // Árbol definido con una lambda:
  Expression<Func<int, bool>> esPar = a => a % 2 == 0;

  // Y el mismo árbol definido a mano, 
  // lo que genera el compilador automáticamente:
  ParameterExpression param = Expression.Parameter(typeof(int), "a");
  ConstantExpression dos = Expression.Constant(2, typeof(int));
  ConstantExpression cero = Expression.Constant(0, typeof(int));
  BinaryExpression modulo = Expression.Modulo(param, dos);
  BinaryExpression comparacion = Expression.Equal(modulo, cero);
  Expression<Func<int, bool>> esPar2 =
       Expression.Lambda<Func<int, bool>>(comparacion, param);

Uso de los árboles de expresión

Ya sabemos qué son los árboles de expresión y cómo podemos definirlos, pero aún no le hemos visto sentido a su existencia. Pero lo tiene, vaya si lo tiene ;-)

En primer lugar, el hecho de poder definir el árbol partiendo de una expresión lambda, además de comodidad a la hora de codificar, nos permite aprovechar el tipado fuerte y la potencia del intellisense para evitar errores. En el ejemplo anterior, las probabilidades de que nos equivoquemos creando el árbol de forma manual son muy superiores a que ocurra si utilizamos la sintaxis lambda.

Segundo, fijaos que en ningún momento se está generando código IL o compilando la expresión representada por la lambda. Estamos creando una estructura en memoria. Esto quiere decir que después podemos procesar esta información como estimemos conveniente; podemos, por ejemplo, analizar su contenido, recorrerlo, seriarlo, o transformarlo, en función de nuestras necesidades. Es ideal, por tanto, cuando tengamos interés en interpretar una expresión para realizar alguna acción con ella.

Vamos a ver ahora varios ejemplos para ilustrar el uso de las lambdas y árboles de expresión en el mundo real.

Linq

En el caso de Linq aplicado a un proveedor externo de datos relacional (por ejemplo, las tecnologías Linq to SQL, o Entity Framework), no tiene interés alguno el código ejecutable asociado a una expresión, sino su estructura, pues al final va a ser traducida al lenguaje o tecnología del almacén de información. Supongamos la siguiente consulta para obtener los productos que comienzan por "S":

  // Usando una consulta Linq:
  var datos = from p in productos 
                 where p.Nombre.StartsWith("S")
                 select p;

  // O su equivalente usando 
  // operadores de consulta:
  var datos = productos.Where(p=>p.Nombre.StartsWith("S"));

La lambda resaltada servirá para crear un árbol de expresión con las condiciones indicadas, pues el método de extensión Where aplicado acepta un predicado de tipo Expression. No se genera ningún método anónimo para la expresión lambda, ni se traduce a IL su contenido: sólo interesa para definir la expresión que será introducida en el árbol. Más adelante, en el momento de extraer realmente la información desde el almacén correspondiente, el componente proveedor de datos recorrerá y analizará la estructura en memoria, generando su equivalente en SQL, que es lo que lanzará al SGBD para obtener los datos.

Por cierto, existen en la actualidad una gran cantidad de proveedores de Linq, capaces de transformar los árboles de expresión en consultas a casi cualquier tipo de almacén. Fijaos que la posibilidad de separar la codificación lambda de la interpretación de la expresión hace posible su utilización en una gran variedad de ámbitos.

Cálculo simbólico

Otro ejemplo que ilustra muy bien las posibilidades de los árboles de expresión, de mano del maestro Octavio Hernández. Se trata del artículo Cálculo simbólico en C# 3.0, publicado en la web de El Guille a principios de 2007.

A lo largo del artículo se realiza la implementación básica de un sistema de cálculo de derivadas de funciones matemáticas partiendo de un árbol de expresiones. El proceso, que el autor va explicando paso a paso, consiste en analizar el árbol, e ir generando otro árbol con el resultado de la derivación de cada expresión encontrada. A continuación se muestra la porción de código donde se realiza la derivación de una operación de suma, utilizando recursividad para derivar además cada uno de los sumandos:

  private static Expression Derive(this Expression e, string paramName)
  {
      switch (e.NodeType)
      {
          [...]
          // sum rule
          case ExpressionType.Add:
              {
                  Expression dleft = 
                     ((BinaryExpression) e).Left.Derive(paramName);
                  Expression dright = 
                     ((BinaryExpression) e).Right.Derive(paramName);
                  return Expression.Add(dleft, dright);
              }
          [...]
      }
  }

Al final, fijaos que de nuevo no nos interesa en absoluto la lambda como función anónima ni delegado, sino la estructura de la propia expresión, de forma que podamos recorrerla y transformarla en otra expresión, en este caso la función derivada de la original. El siguiente ejemplo muestra el uso de esta clase:

   Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  Console.WriteLine(derivada); // Muestra la función derivada:
                               //    x => ((x * 1) + (1 * x))

Creedme, vale la pena echarle un vistazo.

ASP.NET MVC

Un último ejemplo, que demuestra la versatilidad del uso de lambdas y árboles de expresión en multitud de escenarios. En el framework ASP.NET MVC, es posible crear enlaces hacia acciones desde dentro de las vistas (páginas .ASPX), que no son sino métodos dentro de unas clases concretas llamadas "controladores". El caso es que para hacer referencia a un método del controlador, pueden utilizarse estas dos vías, de resultado idéntico:

  // Obtiene un enlace al método "ChangePassword"
  // de la clase "AccountController":
  Html.ActionLink("Cambiar clave", "ChangePassword", "Account")

  // Lo mismo, pero usando un árbol de expresión:
  Html.ActionLink<AccountController>
              (acc=>acc.ChangePassword(), "Cambiar clave")

Aunque el resultado es el mismo, la segunda usa un árbol de expresión para realizar la referencia al método ChangePassword de la clase AccountController. La implementación del método ActionLink recorre el árbol generado desde la expresión lambda para obtener el nombre del controlador y del método, por lo que es equivalente a primera fórmula, pero beneficiándose de las ventajas del tipado fuerte y del intellisense en la edición.

Los árboles de expresión como código ejecutable

Hasta ahora siempre me he referido a los árboles de expresión como entidades de almacenamiento. De alguna u otra forma, estaba equiparando su utilidad a la cualquier estructura de datos que permitiera guardar y procesar información, lo cual es cierto pero sólo parcialmente.

Los árboles de expresión aportan una característica adicional: se pueden convertir en código ejecutable. Es decir, es posible compilar un árbol de expresión en tiempo de ejecución, dando lugar a una función anónima a la que podemos tener acceso, es decir, invocarla, a través de sus delegados.

Veámoslo con un caso concreto. Retomando el ejemplo de obtención de derivadas, sería perfectamente posible obtener el valor de la función derivada en un punto ampliando ligeramente el código visto anteriormente:

  Expression<Func<double, double>> 
                funcion = x => x*x;          // f(x)=x^2

  Expression<Func<double, double>> 
                derivada = funcion.Derive(); // f'(x)=2*x

  // Compilamos la función derivada
  // y obtenemos un delegado a la misma:
  Func<double, double> funcDerivada = derivada.Compile();

  double result = funcDerivada(6); // Obtenemos el valor de la función 
                                   // invocando al delegado con x=6
  Console.WriteLine(result);       // Muestra "12"

Como se puede observar en el código, la llamada al método Compile() devuelve un delegado del tipo Func indicado en el parámetro genérico de la expresión, que apunta hacia la función anónima creada "al vuelo" a partir de las expresiones contenidas en el árbol. Es decir, desde la definición simbólica contenida en el árbol ¡obtenemos código ejecutable!

Aunque espectacular, en realidad no hay nada mágico en esta característica: se trata de ir recorriendo el árbol y emitiendo el código IL correspondiente a cada expresión, que está perfectamente tipificada y definida. En el namespace System.Linq.Expressions existe una bonita clase interna llamada ExpressionCompiler que se dedica exclusivamente a ello, utilizando herramientas suministradas por System.Reflection.Emit, como los generadores de lenguaje intermedio ILGenerator.

¡Y hasta aquí hemos llegado!

A lo largo de estos tres posts hemos recorrido las principales características y utilidades de las expresiones lambda. Obviamente, han quedado cosas por detrás; no era objetivo de esta serie profundizar demasiado, sino ofrecer una visión suficiente para animar a los desarrolladores a utilizar esta potente característica que nos ofrece C# (y VB.NET).

Espero que os haya sido una lectura útil, al menos tanto como me ha resultado a mí su escritura. Ah, y para consultas, sugerencias o puntualizaciones, por aquí me tenéis.

Publicado en: www.variablenotfound.com.

C#: Desmitificando las expresiones lambda (II)

José M. Aguilar — Tue, 21 Apr 2009 21:54:00 GMT

En el post anterior intentamos realizar una primera aproximación a las expresiones lambda, centrándonos en obtener una definición lo suficientemente cercana, que nos permitiera conocer a grandes rasgos qué son, así como en describir su forma general y sus particularidades sintácticas.

En esta segunda entrega vamos a profundizar un poco en el papel de las expresiones lambda como vía para definir muy rápidamente funciones anónimas y los tipos de delegados con los que podemos referenciarlas, y por tanto, invocarlas.

Ya en el tercer post describiremos el papel de las expresiones lambda como herramienta de generación de árboles de expresión.

Las lambdas como funciones anónimas

Como habíamos insinuado anteriormente, uno de los usos de las expresiones lambda es permitir la definición "en línea" de funciones anónimas. De hecho, en tiempo de compilación las expresiones lambda son convertidas en métodos a los que el compilador establece un nombre único autogenerado, como los ejemplos mostrados a continuación:

Las referencias a estas funciones anónimas son transformadas en delegados (punteros) a las mismas, lo que nos permitirá, por ejemplo, invocarlas desde el código. En la práctica esto quiere decir que podemos asignar una lambda a una variable y ejecutarla como muestra el siguiente pseudocódigo:


  delegado duplica = x => x * 2; 
  escribe duplica(2); // Escribe un 4

En este primer acercamiento, fijaos que duplica es el nombre del delegado, la función definida en forma de expresión lambda no tiene nombre, será el compilador el que se asigne uno.

Veamos cómo se concreta esta idea en C#. En el siguiente código, la variable duplica apunta hacia una función anónima definida a través de la expresión lambda en cuya implementación lo único que se hace es retornar el doble del valor que le llega como parámetro. Vemos también cómo podemos utilizarla de forma directa:

  Func<int, int> duplica = x => x * 2;
  int result = duplica(7); // result vale 14

Sólo con objeto de que podáis entender el código anterior, os adelantaré que la porción Func<int, int> es una forma rápida de tipificar el delegado, indicando que duplica apunta a una función que espera un entero como parámetro de entrada, y que su valor de retorno será otro entero. Esto lo veremos dentro de un momento.

De la misma forma que asignamos la expresión lambda a una variable, podemos hacerlo también para indicar el valor de un parámetro a un método que acepte un delegado concreto. Por ejemplo, el siguiente código muestra un método llamado calcula que recibe un valor entero y una referencia a una función, retornando el resultado de efectuar dicha operación sobre el entero proporcionado:

  // Es método ejecuta la función indicada por
  // el parámetro operacion, enviándole el valor especificado, 
  // y retorna el resultado obtenido de la misma.
  public int calcula(int valor, Func<int, int> operacion)
  {
    return operacion(valor); // retorna el resultado de aplicar la 
                             // expresión indicada al valor.
  }

  // Usos posibles:
  int i = calcula(4, x => x / 2); // Le pasamos una referencia a la 
                                  // función que estamos definiendo sobre
                                  // la marcha. El resultado es que i=2.

  int j = calcula(4, duplica);    // Le pasamos la variable "duplica", 
                                  // que es una referencia a la lambda
                                  // definida anteriormente. J valdrá 8.

<HistoriaDelAbuelete>
Seguro que a los más viejos del lugar esto le recuerda a los Codeblocks que utilizábamos en Clipper a principios de los 90 (uuf, cómo pasa el tiempo...). ¿Todavía reconocéis el siguiente código?

  bDuplica := { |n| n*2 }
  ? EVAL(bDuplica, 7)     // Muestra un 14

</HistoriaDelAbuelete>

Una consecuencia directa de que las expresiones lambdas sean referenciadas a través de delegados es que podemos utilizarlas en cualquier sitio donde se acepte un delegado, con la única precaución de escribirla teniendo en cuenta el tipo de su retorno y los parámetros que recibe. Un ejemplo claro lo tenemos en la suscripción a eventos, donde la técnica habitual consiste en utilizar un delegado a un método en el que se implementa la lógica del tratamiento de los mismos, algo como:

  // Nos suscribimos al evento MouseMove:
  this.MouseMove += new MouseEventHandler(this.Form1_MouseMove);
  [...]

  // Tratamiento del evento MouseMove:
  private void Form1_MouseMove(object sender, MouseEventArgs e)
  {
    this.Text = e.X + "," + e.Y;
  }

Como sabemos, podemos suscribirnos al evento MouseMove añadiéndole delegados del tipo MouseEventHandler, definido en System.Windows.Forms, cuya firma indica que recibe un parámetro de tipo object, otro de tipo MouseEventArgs y no retorna ningún valor, exactamente igual que sería un delegado anónimo (C# 2.0) escrito así:

  this.MouseMove += delegate(object sender, MouseEventArgs args)
  {
    this.Text = args.X + "," + args.Y;
  };

Y dado que las lambdas pueden sustituir de forma directa a cualquier delegado, podemos utilizarlas para conseguir un código más compacto:

  this.MouseMove += (sender, args) => {
                       this.Text = args.X + "," + args.Y;
                    };

Llegados a este punto es conveniente aclarar que las expresiones lambda son características introducidas en los lenguajes, y por tanto en sus compiladores, pero no en la plataforma de ejecución (CLR) en sí. Por tanto, todo lo descrito hasta el momento era posible realizarlo antes que las lambda aparecieran por el horizonte, aunque de forma un poco más tediosa, utilizando mecanismos que la versión 2.0 del framework ponía a nuestra disposición, como los delegados y métodos anónimos. En este sentido, el uso de expresiones lambda aportan mucha simplicidad, elegancia y legibilidad al código.

Esto explica, además, que Visual Studio 2008 sea capaz de generar código para .NET 2.0 a partir de código fuente C# 3.0.

Tipos de delegados de expresiones lambda

Antes ya había adelantado que la definición Func<int, int> era simplemente una forma de indicar el tipo del parámetro que recibía la función lambda, así como el tipo del valor de retorno. En realidad, lo único que estábamos haciendo era definir, de forma muy sencilla y rápida, el delegado hacia la función.

Vamos a concretar esto un poco más, pero antes de continuar, una cosa: si para tí un genérico es un tipo de medicamento, mejor que leas algo sobre el tema antes de continuar, pues en caso contrario es posible que te pierdas un poco ;-). Pues probar leyendo una introducción a los generics en c#, o la Guía de programación de C#.

.NET Framework ofrece en el espacio de nombres System un conjunto de definiciones de genéricas de delegados para que podamos utilizarlos para "apuntar" hacia las funciones definidas mediante expresiones lambda, llamados Action y Func.

Utilizaremos los tipos Func para definir referencias a expresiones lambda que retornen un valor, o sea, funciones. De ahí su nombre. Los tipos Action, en cambio, están destinados a referenciar a lambdas que realicen acciones y que no retornen ningún valor. De ahí su nombre también. ;-)

Una de estas definiciones es la que habíamos usado en un ejemplo anterior:

  Func<int, int> duplica = x => x * 2;

Como se puede observar, al tratarse de una referencia a una función que retorna un valor, hemos utilizado un tipo Func con dos parámetros genéricos, que corresponde con la siguiente declaración existente en el espacio de nombres System:

  public delegate TResult Func<T, TResult>(T arg);

Por ello, cuando declarábamos que la variable duplica era del tipo Func<int, int>, lo que indicábamos era, en primer lugar que el parámetro que necesitaba la lambda era un int, y que ésta nos devolvería también un int, es decir, lo mismo que si hubiéramos definido duplica así, utilizando métodos anónimos de C# 2.0:

  // En el área de declaraciones:
  public delegate int Duplicador(int arg);
  ...
  // En el código:
  Duplicador duplica = delegate(int k) { return k*2 };

Obviamente, la sintaxis lambda es mucho más compacta y expresiva.

En la práctica, lo único que tenemos que tener claro a la hora de referenciar una función lambda es el tipo de cada uno de los parámetros que usa, y el tipo de retorno. Estos se introducen, en ese orden, en los parámetros genéricos de la clase Func y listo. Como esto debe quedar claro, ahí van unos ejemplos de definición y uso:

  // Recibe un entero y retorna un booleano:
  Func<int, bool> esPar = x => x%2==0;     
  Console.WriteLine(esPar(2)); // Muestra "True"

  // Recibe dos enteros, retorna otro entero:
  Func<int, int, int> suma = (a,b) => a+b;
  Console.WriteLine(suma(2,3)); // Muestra "5"

  // No recibe nada, retorna un texto:
  Func<string> hora = () => "Son las "
                             + DateTime.Now.ToShortTimeString();
  Console.WriteLine(hora()); // Muestra "Son las 14:21:10"

Es importante saber que en el framework están definidos los delegados Func<tipo1, tipo2..., tipoResult> para funciones de hasta cuatro parámetros. Si necesitamos más deberemos definir los delegados a mano, aunque esto es realmente sencillo utilizando una de las declaraciones existentes y añadiéndole el número de parámetros que deseemos. Por ejemplo, para seis parámetros la definición del genérico sería algo así como:

  public delegate 
         TResult Func<T1, T2, T3, T4, T5, T6, TResult>
                 (T1 p1, T2 p2, T3 p3, T4 p4, T5 p5, T6 p6);

Pero ahora aparece un pequeño problema: las funciones sin retorno no pueden referenciarse con delegados de tipo Func, puesto que el framework .NET no soporta la instanciación de tipos genéricos utilizando parámetros void (ECMA 335, sección 9.4, pág. 153). Por tanto, no podríamos declarar un delegado como Func<int, void> para apuntar hacia una función que recibe un entero y no devuelve nada. Si lo pensáis un poco, este es el motivo de que no exista ninguna sobrecarga de la clase Func sin parámetros genéricos, pues como mínimo debemos indicar el tipo del valor de retorno.

La clave para cubrir estos casos se encuentra en el tipo Action. Como comentaba unas líneas más arriba, el objeto de estos tipos de delegados es apuntar a expresiones lambda que realicen acciones y que no retornen ningún valor, por lo que sus parámetros genéricos describirán exclusivamente los tipos de los parámetros de la función. En este caso, como es obvio, sí existe una clase no parametrizada Action para apuntar a funciones sin parámetros, además de disponer de genéricos que cubren las acciones de hasta cuatro parámetros. Veamos unos ejemplos:

  // Acción sin parámetros (no genérica):
  Action saluda = () => Console.WriteLine("hola");
  saluda();  // Muestra "hola";

  // Acción que recibe un string
  Action<string> apaga = motivo => { 
                                      log(motivo);
                                      shutdown();
                                   };
  apaga("mantenimiento"); // Apaga el sistema

Por último, me parece interesante recordar algo que había comentado en el post anterior, que en las expresiones lambda no era necesario indicar el tipo de los parámetros ni del retorno porque el compilador los infería del contexto. Como podemos ver, lo tiene bastante fácil, puesto que simplemente debe tomar la definición del delegado para conocerlos; por eso no es necesario introducir redundancias como las siguientes:

  Func<int, int> duplica = (int a) => (int)(a * 2); // ¡Redundante!

  // Forma más cómoda:

  Func<int, int> duplica =  a => a * 2; // Ok!

En cualquier caso, si por algún motivo es necesario utilizar la forma explícita, sabed que no se permite hacerlo de forma parcial, es decir, o le ponéis los tipos a todo, o no se los ponéis a nada.

Y hasta aquí esta segunda entrega. En el siguiente post, el último de la serie, estudiaremos el uso de las

lambda como herramientas de definición de árboles de expresión.

Por supuesto, para cualquier duda o sugerencia, ya sabéis dónde encontrarme. :-)

Publicado en: www.variablenotfound.com.

C#: Desmitificando las expresiones lambda (I)

José M. Aguilar — Sun, 12 Apr 2009 21:59:00 GMT

Entre las múltiples novedades aparecidas con C# 3.0 y VB.NET 9.0, las expresiones lambda son sin duda una de las que en principio pueden parecer más complejas, probablemente por su relación con conceptos no demasiado asimilables como los delegados, inferencia de tipado, métodos anónimos, o tipos genéricos, entre otros.

Sin embargo, esa aparente dificultad desaparece en cuanto se les presta un poco de atención, y una vez comprendidas aportan a los desarrolladores una potencia y agilidad difíciles de lograr con las herramientas disponibles hasta el momento. Sólo hay que ver su amplia utilización dentro del propio .NET framework, LINQ, y nuevas plataformas como ASP.NET MVC, para darse cuenta de su importancia. Y por si fuera poco, según cuentan los expertos, su uso "engancha".

A lo largo de esta serie de tres posts intentaré describir las expresiones lambda desde un punto de vista práctico, con la única pretensión de aportar algo de luz a los que todavía no han sucumbido a su poder. ;-)

El objetivo de este primer post es puramente introductorio, y trataré conceptos y nociones básicas para poder abordar los siguientes. En el segundo post de la serie trataremos las expresiones lambda como funciones anónimas, dejando para el tercero los misteriosos árboles de expresión.

Introducción a las lambda

Según la definición en la Referencia del lenguaje C# de MSDN:

"Una expresión lambda es una función anónima que puede contener expresiones e instrucciones y se puede utilizar para crear delegados o tipos de árboles de expresión"

En la Guía de programación de Visual Basic 9 encontramos otra definición, muy simple y pragmática:

"Una expresión lambda es una función sin nombre que calcula y devuelve un solo valor. Se pueden utilizar las expresiones lambda dondequiera que un tipo de delegado sea válido"

ScottGu también aportó su granito de arena para hacer el concepto más cercano a los desarrolladores; como siempre, al grano:

"Las Expresiones Lambda aportan una sintaxis más concisa y funcional para escribir métodos anónimos."
[...]
"La forma más sencilla para conceptualizar las expresiones lambda es pensar en ellas como formas de escribir métodos breves en una línea."

Partiendo de estas definiciones, y de otras muchas aportadas por Google ;-), está claro que las lambda son funciones, es decir, un conjunto de intrucciones capaces de retornar un valor partiendo de los parámetros que se les suministra, aunque en determinados casos es posible que no reciba ningún parámetro, o que realicen una acción sin retornar nada. Igual que una función tradicional, vaya. Y de hecho, en el cuerpo de una expresión lambda puede haber casi de todo: llamadas a otras funciones, expresiones, bucles, declaraciones de variables...

Sin embargo, a diferencia de los métodos o funciones habituales, las lambdas no necesitan de un identificador, puesto que se declaran in situ, justo en el momento en que van a asignarse a una variable o a utilizarse como parámetro de una función, pasando el destinatario de esta asignación a actuar como delegado, o puntero, hacia la misma, o a ser el contenedor del árbol de expresión que la representa. Ein? Chino, eh? No pasa nada, dentro de poco estudiaremos estos dos usos en profundidad, pero antes vamos a ver cómo se definen las expresiones lambda a nivel de código.

Forma de las expresiones lambda

Las expresiones lambda en C# se escriben según el patrón descrito a continuación, al que le siguen algunos ejemplos que lo ilustran e introducen algunas particularidades.

Forma general: parámetros => expresión, donde:
- parámetros: lista de parámetros separados por comas
- "=>" : separador.
- expresión: implementación de las operaciones a realizar

num => num * 2     // Lambda con un parámetro que retorna
                   // el doble del valor que se le pasa.

(a, b) => a + b    // Lambda con dos parámetros que retorna
                   // la suma de ambos.

num => {                        // Lambda con cuerpo que recibe un 
   int x = new Random().Next(); // entero, y retorna la suma de éste
   return num+x;                // con un número aleatorio.
}  

() => DateTime.Now // Lambda que no recibe parámetros
                   // y retorna la fecha y hora del sistema.

msg => Console.WriteLine(msg); // Recibe un parámetro, realiza una
                               // acción y no retorna nada.

Como se puede observar, cuando sólo existe un parámetro no es necesario utilizar paréntesis en el lado izquierdo de la expresión, mientras que hay que hacerlo en todos los demás casos. También es interesante destacar que las lambda con cuerpo deben utilizar return para retornar el valor deseado, cuando esto sea necesario.

Y un último dato: fijaos que ni los parámetros ni el retorno de la función tienen indicado un tipo. Aunque puede hacerse, normalmente no será necesario puesto que el compilador podrá inferir (deducir) el tipo a partir de su contexto, más adelante veremos cómo es esto posible. Por tanto, no es necesario escribir código tan extenso como:

  (int a, int b) => (int)(a+b)

Y hasta aquí este primer post introductorio. En el siguiente trataremos de explicar el papel de las expresiones lambda como funciones anónimas y facilitadoras del trabajo con delegados.

Continuar leyendo la siguiente entrega: C#: Desmitificando las expresiones lambda (II)

Publicado en: www.variablenotfound.com.

Inclusión de elementos en el encabezado de una página de contenidos ASP.NET

José M. Aguilar — Tue, 27 Jan 2009 22:50:00 GMT

Un detalle que llama la atención al añadir una página maestra a un proyecto ASP.NET desde Visual Studio 2008 es que, por defecto, añade dos secciones de contenido (ContentPlaceHolder) a la estructura de la página.

Una de ellas es la habitual, en el cuerpo de <form runat="server">, que es donde las páginas basadas en esa MasterPage introducirán sus contenidos y controles. La otra, sin embargo, es una novedad respecto a versiones anteriores del IDE: en la sección <head> del documento:

<head runat="server">
    <title></title>
    <asp:ContentPlaceHolder ID="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
        </asp:ContentPlaceHolder>
    </div>
    </form>
</body>
</html>

Como habréis deducido, esto nos permite introducir contenidos personalizados en la sección <head> de una página concreto, como meta tags, o referencias a scripts que deseamos que se carguen con la página, evitando tener que incluirlos mediante programación. Así, si por ejemplo deseamos introducir una referencia a la librería jQuery en una página, la implementación de ésta incluiría los dos placeholders, tal y como sigue:

<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
   <script type="text/javascript" src="/scripts/jquery.js"></script>
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
   <!-- contenidos del webform -->
</asp:Content>

La buena noticia para los que todavía trabajamos con Visual Studio 2005 es que podemos aplicar esta misma técnica desde esta versión. Aunque por defecto el IDE no incluye el ContentPlaceHolder en el encabezado, podemos añadirlo a mano para que quede como en el código mostrado anteriormente, y el efecto será idéntico.

Eso sí, a cambio tendremos que aguantar que el entorno nos avise de que la etiqueta no es correcta en ese punto, puesto que sólo VS2008 es capaz de interpretarlo correctamente, pero se trata sólo de un molesto aviso, que no influirá en la compilación o ejecución de las páginas.

Publicado en: www.variablenotfound.com.

Microsoft Chart Control para ASP.NET 3.5 SP1

José M. Aguilar — Sun, 14 Dec 2008 22:47:00 GMT

Pues tiene una pinta excelente el control para la generación de gráficas estadísticas Chart Control para ASP.NET 3.5, recientemente presentado en sociedad por Scottgu (con la habitual traducción en Thinking in .net).

Se trata de un componente con una versión específica para ASP.NET, válida para WebForms y MVC framework, y otra para Windows Forms, que permite generar gráficas estadísticas prácticamente de cualquier tipo, visualmente muy atractivas, realmente fáciles de utilizar en nuestas aplicaciones y, además, de forma gratuita.

Enumero características interesantes, o que me han llamado la atención (ambas cosas no están necesariamente unidas ;-)), del control para ASP.NET:

El control se renderiza en cliente con una etiqueta <img>.
Se puede forzar al control a generar las imágenes al vuelo o a almacenarlas físicamente en una carpeta.
Las imágenes generadas pueden ser cacheadas para mejorar el rendimiento.
Genera BMPs, JPGs, PNGs o EMFs.
Permite también usarlo con aplicaciones no ASP.NET 3.5 a través del modo "binary streaming", que fuerza a que el control elimine toda la salida HTML de la página donde se encuentra y retorne únicamente la imagen como resultado, de forma dicha página puede ser utilizada como source de un tag <img> en otro sitio.

Soporta eventos del tipo "PrePaint" y "PostPaint" para poder hacer retoques a mano sobre los resultados, como:

void Chart1_PostPaint(object sender, ChartPaintEventArgs e)
{
  e.ChartGraphics.Graphics.DrawString("Hola", 
                                      new Font("Arial", 12f), 
                                      Brushes.Black, 10, 10);
}

25 tipos de gráficas, muchas de ellas con vistas en tres dimensiones, en las que se puede modificar prácticamente todo: rotación, inclinación, sombras, etc.
Podemos crear imágenes con múltiples gráficas distintas, utilizar en ellas todas las series de datos que deseemos, con un número ilimitado de puntos.
Control total sobre los ejes en cuanto a escalado, visualización o etiquetado.
Posibilidad de añadir anotaciones, leyendas y otros elementos "extra".
Permite establecer datos enlazando el control a fuentes (binding), o de forma manual sobre el mismo utilizando los diseñadores o etiquetas ASP.NET.
Soporta mapeo de imágenes, posibilidad de capturar clicks sobre áreas para establecer comportamientos personalizados, o combinarlo con Ajax para enriquecer la experiencia de usuario.

Instalación

Antes de instalar, asegúrate que cumples el requisito previo básico, tener instalado Microsoft .NET Framework 3.5 SP1. Si no lo has hecho antes, ya sabes por dónde empezar ;-)

Una vez asegurado este punto, el siguiente paso es descargar Microsoft Chart Control, que incluye controles tanto para ASP.NET como para Windows Forms. Existe también, como descarga opcional, el paquete de idioma para Microsoft Chart Control, que contiene la localización del producto para otros idiomas.

Después, es una buena idea instalar el Add-on para Visual Studio 2008 que os facilitará el trabajo con el control desde este entorno de desarrollo, a base de diseñadores integrados. No olvidéis también bajaros también la documentación si váis a necesitar información detallada de las librerías incluidas.

Y, por último, para tomar conciencia del tipo de resultados que se pueden obtener con este control, el ideal es descargar los proyectos de demostración, que os permitirán ver y tocar una auténtica batería de ejemplos seguro muy útiles a la hora de usarlo en vuestros desarrollos, tanto ASP.NET como Winforms.

Publicado en: www.variablenotfound.com.

Métodos genéricos en VB.NET

José M. Aguilar — Mon, 08 Dec 2008 22:20:00 GMT

Al escribir el post "Métodos genéricos en C#", estuve pensando en tratar este tema también en VB.NET de forma simultánea, pero al final preferí limitarme a C# para no hacer la entrada más extensa de lo que ya iba a resultar de por sí.

Esto, unido a un comentario de Julio sobre el propio post en el que preguntaba si existía algo parecido en Visual Basic .NET, ha hecho que reedite el mismo, pero centrándome esta vez en dicho lenguaje.

Los métodos genéricos son interesantes herramientas que están con nosotros desde los tiempos del .NET Framework 2.0 y pueden resultarnos muy útiles de cara a la construcción de frameworks o librerías reutilizables.

Podríamos considerar que un método genérico es a un método tradicional lo que una clase genérica a una tradicional; por tanto, se trata de un mecanismo de definición de métodos con tipos parametrizados, que nos ofrece la potencia del tipado fuerte en sus parámetros y devoluciones aun sin conocer los tipos concretos que utilizaremos al invocarlos.

Vamos a profundizar en el tema desarrollando un ejemplo, a través del cual podremos comprender por qué los métodos genéricos pueden sernos muy útiles para solucionar determinado tipo de problemas, y describiremos ciertos aspectos, como las restricciones o la inferencia, que nos ayudarán a sacarles mucho jugo.

Escenario de partida

Como sabemos, los métodos tradicionales trabajan con parámetros y retornos fuertemente tipados, es decir, en todo momento conocemos los tipos concretos de los argumentos que recibimos y de los valores que devolvemos. Por ejemplo, en el siguiente código, vemos que el método Maximo, cuya misión es obvia, recibe dos valores Integer y retorna un valor del mismo tipo:

  Function Maximo(ByVal uno As Integer, ByVal otro As Integer) _
                  As Integer
    If uno > otro Then Return uno
    Return otro
  End Function

Hasta ahí, todo correcto. Sin embargo, está claro que retornar el máximo de dos valores es una operación que podría ser aplicada a más tipos, prácticamente a todos los que pudieran ser comparados. Si quisiéramos generalizar este método y hacerlo accesible para otros tipos, se nos podrían ocurrir al menos dos formas de hacerlo.

La primera sería realizar un buen puñado de sobrecargas del método para intentar cubrir todos los casos que se nos puedan dar:


  Function Maximo(ByVal uno As Integer, ByVal otro As Integer) _
                  As Integer
    ' ...  
  End Function
  Function Maximo(ByVal uno As Long, ByVal otro As Long) _
                  As Long
    ' ...  
  End Function
  Function Maximo(ByVal uno As Decimal, ByVal otro As Decimal) _
                  As Decimal
    ' ...  
  End Function

  ' Y así hasta que te aburras...

Obviamente, sería un trabajo demasiado duro para nosotros, desarrolladores perezosos como somos. Además, según Murphy, por más sobrecargas que creáramos seguro que siempre nos faltaría al menos una: justo la que vamos a necesitar ;-).

Otra posibilidad sería intentar generalizar utilizando las propiedades de la herencia. Es decir, si asumimos que tanto los valores de entrada del método como su retorno son del tipo base Object, aparentemente tendríamos el tema resuelto. Lamentablemente, al finalizar nuestra implementación nos daríamos cuenta de que no es posible hacer comparaciones entre dos Object's, por lo que, o bien incluimos en el cuerpo del método código para comprobar que ambos sean comparables (consultando si implementan IComparable), o bien elevamos el listón de entrada a nuestro método, así:

  Function Maximo(ByVal uno As IComparable, ByVal otro As Object) As Object
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

Pero efectivamente, como ya habréis notado, esto tampoco sería una solución válida para nuestro caso. En primer lugar, el hecho de que ambos parámetros sean Object o IComparable no asegura en ningún momento que sean del mismo tipo, por lo que podría invocar el método enviándole, por ejemplo, un String y un Integer, lo que provocaría un error en tiempo de ejecución. Y aunque es cierto que podríamos incluir código que comprobara que ambos tipos son compatibles, ¿no tendríais la sensación de estar llevando a tiempo de ejecución problemática de tipado que bien podría solucionarse en compilación?

El método genérico

Fijaos que lo que andamos buscando es simplemente alguna forma de representar en el código una idea conceptualmente tan sencilla como: "mi método va a recibir dos objetos de un tipo cualquiera T, que implemente IComparable, y va a retornar el que sea mayor de ellos". En este momento es cuando los métodos genéricos acuden en nuestro auxilio, permitiendo definir ese concepto como sigue:

  Function Maximo(Of T As IComparable) _
                 (ByVal uno As T, ByVal otro As T) As T
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

En el código anterior, podemos distinguir una porción de código que aparece resaltada justo después del nombre del método, y antes de comenzar a definir sus parámetros. Es la forma de indicar que Maximo es un método genérico y operará sobre un tipo cualquiera al que llamaremos T, y mediante una restricción estamos indicando que deberá implementar obligatoriamenter el interfaz IComparable (más adelante trataremos esto en profundidad).

A continuación, podemos observar que los dos parámetros de entrada son del tipo T, así como el retorno de la función. Si no lo ves claro, sustituye mentalmente la letra T por Integer (por ejemplo) y seguro que mejora la cosa.

Lógicamente, estos métodos pueden presentar un número indeterminado de parámetros genéricos, como en el siguiente ejemplo. Observad que la palabra clave Of sólo se indica al principio:

  Function MiMetodo(Of T1, T2, TResult) _
                   (ByVal par1 As T1, ByVal par2 As T2) As TResult

Y una aclaración antes de continuar: lo de usar la letra T para identificar el tipo es pura convención, podríamos llamarlo de cualquier forma (por ejemplo Maximo(Of MiTipo)(ByVal uno as MiTipo, ByVal otro as MiTipo) As MiTipo), aunque ceñirse a las convenciones de codificación es normalmente una buena idea.

Restricciones en parámetros genéricos

Retomemos un momento el código de nuestro método genérico:

  Function Maximo(Of T As IComparable) _
                 (ByVal uno As T, ByVal otro As T) As T
    If uno.CompareTo(otro) > 0 Then Return uno
    Return otro
  End Function

Antes había comentado que en este caso estabamos creando un método que podría actuar sobre cualquier tipo, aunque mediante una restricción forzábamos a que éste implementara, obligatoriamente, el interfaz IComparable, lo que nos permitiría realizar la operación de comparación que necesitamos.

Obviamente, las restricciones no son obligatorias; de hecho, sólo debemos utilizarlas cuando necesitemos limitar de alguna forma los tipos permitidos como parámetros genéricos, como en el ejemplo anterior. Está permitida la utilización de las siguientes reglas:

As Structure, indica que el argumento debe ser un tipo valor.
As Class, indica que T debe ser un tipo referencia.
As New, fuerza a que el tipo T disponga de un constructor público sin parámetros; es útil cuando desde dentro del método se pretende instanciar un objeto del mismo.
As nombredeclase, indica que el argumento debe heredar o ser de dicho tipo.
As nombredeinterfaz, el argumento deberá implementar el interfaz indicado.
As nombredetipogenérico, indica que el argumento al que se aplica debe ser igual o heredar del tipo, también argumento del método, indicado por nombredetipogenérico (observad en el siguiente ejemplo el parámetro T2).

Un último detalle relativo a esto: a un mismo parámetro se pueden aplicar varias restricciones, en cuyo caso se introducirán entre llaves ("{" y "}") separadas por comas, como aparece en el siguiente ejemplo:

  Function MiMetodo(Of T1 As {Class, IEnumerable}, _
                       T2 As {T1, New}, _
                       TResult As New) _
                   (ByVal par1 As T1, ByVal par2 As T2) As TResult
    ' ... Cuerpo del método
  End Function

Uso de métodos genéricos

A estas alturas ya sabemos, más o menos, cómo se define un método genérico, pero nos falta aún conocer cómo podemos consumirlos, es decir, invocarlos desde nuestras aplicaciones. Aunque puede intuirse, la llamada a los métodos genéricos debe incluir tanto la tradicional lista de parámetros del método como los tipos que lo concretan. Vemos unos ejemplos:

  Dim mazinger As String = Maximo(Of String)("Mazinger", "Afrodita")
  Dim i99 As Integer = Maximo(Of Integer)(2, 99)

Una interesantísima característica de la invocación de estos métodos es la capacidad del compilador para inferir, en muchos casos, los tipos que debe utilizar como parámetros genéricos, evitándonos tener que indicarlos de forma expresa. El siguiente código, totalmente equivalente al anterior, aprovecha esta característica:

  Dim mazinger As String = Maximo("Mazinger", "Afrodita")
  Dim i99 As Integer = Maximo(2, 99)

El compilador deduce el tipo del método genérico a partir de los que estamos utilizando en la lista de parámetros. Por ejemplo, en el primer caso, dado que los dos parámetros son String, puede llegar a la conclusión de que el método tiene una signatura que coincide con la definición del genérico, utilizando String como tipo parametrizado.

Otro ejemplo de método genérico

Veamos un ejemplo un poco más complejo. El método CreaLista, aplicable a cualquier clase, retorna una lista genérica (List(Of T)) del tipo parametrizado del método, que rellena inicialmente con los argumentos (variables) que se le suministra:

  Function CreaLista(Of T)(ByVal ParamArray pars() As T) As List(Of T)
    Dim list As New List(Of T)
    For Each elem As T In pars
      list.Add(elem)
    Next
    Return list
  End Function

  ' ...
  ' Uso:
  Dim nums = CreaLista(Of Integer)(1, 2, 3, 4, 5, 6, 7)
  Dim noms = CreaLista(Of String)("Pepe", "Juan", "Luis")

Otros ejemplos de uso, ahora beneficiándonos de la inferencia de tipos:

  Dim nums = CreaLista(1, 2, 3, 4, 5, 6, 7)
  Dim noms = CreaLista("Pepe", "Juan", "Luis")

  ' Incluso con tipos anónimos de VB.NET 9
  Dim v = CreaLista( _
                     New With {.X = 1, .Y = 2}, _
                     New With {.X = 3, .Y = 4} _
                   )
  Console.WriteLine(v(1).Y) ' Muestra "4"

En resumen, se trata de una característica de la plataforma .NET, reflejada en lenguajes como C# y VB.Net, que está siendo ampliamente utilizada en las últimas incorporaciones al framework, y a la que hay que habituarse para poder trabajar eficientemente con ellas.

Publicado en: www.variablenotfound.com.

Métodos genéricos en C#

José M. Aguilar — Tue, 25 Nov 2008 22:32:00 GMT

Los métodos genéricos son interesantes herramientas que están con nosotros desde los tiempos del .NET Framework 2.0 y pueden resultarnos muy útiles de cara a la construcción de frameworks o librerías reutilizables.

Podríamos considerar que un método genérico es a un método tradicional lo que una clase genérica a una tradicional; por tanto, se trata de un mecanismo de definición de métodos con tipos parametrizados, que nos ofrece la potencia del tipado fuerte en sus parámetros y devoluciones aun sin conocer los tipos concretos que utilizaremos al invocarlos.

Vamos a profundizar en el tema desarrollando un ejemplo, a través del cual podremos comprender por qué los métodos genéricos pueden sernos muy útiles para solucionar determinado tipo de problemas, y describiremos ciertos aspectos, como las restricciones o la inferencia, que nos ayudarán a sacarles mucho jugo.

Escenario de partida

  public int Maximo(int uno, int otro)
  {
    if (uno > otro) return uno;
    return otro;
  }

  public int Maximo(int uno, int otro) { ... }
  public long Maximo(long uno, long otro) { ... }
  public string Maximo(string uno, string otro) { ... }
  public float Maximo(float uno, float otro) { ... }
  // Hasta que te aburras...

Obviamente, sería un trabajo demasiado duro para nosotros, desarrolladores perezosos como somos. Además, según Murphy, por más sobrecargas que creáramos seguro que siempre nos faltaría al menos una: justo la que vamos a necesitar ;-).

Otra posibilidad sería intentar generalizar utilizando las propiedades de la herencia. Es decir, si asumimos que tanto los valores de entrada del método como su retorno son del tipo base object, aparentemente tendríamos el tema resuelto. Lamentablemente, al finalizar nuestra implementación nos daríamos cuenta de que no es posible hacer comparaciones entre dos object's, por lo que, o bien incluimos en el cuerpo del método código para comprobar que ambos sean comparables (consultando si implementan IComparable), o bien elevamos el listón de entrada a nuestro método, así:

  public object Maximo(IComparable uno, object otro)
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

Pero efectivamente, como ya habréis notado, esto tampoco sería una solución válida para nuestro caso. En primer lugar, el hecho de que ambos parámetros sean object o IComparable no asegura en ningún momento que sean del mismo tipo, por lo que podría invocar el método enviándole, por ejemplo, un string y un int, lo que provocaría un error en tiempo de ejecución. Y aunque es cierto que podríamos incluir código que comprobara que ambos tipos son compatibles, ¿no tendríais la sensación de estar llevando a tiempo de ejecución problemática de tipado que bien podría solucionarse en compilación?

El método genérico

  public T Maximo<T>(T uno, T otro) where T: IComparable
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

En el código anterior, podemos distinguir el parámetro genérico T encerrado entre ángulos "<" y ">", justo después del nombre del método y antes de comenzar a describir los parámetros. Es la forma de indicar que Maximo es genérico y operará sobre un tipo cualquiera al que llamaremos T; lo de usar esta letra es pura convención, podríamos llamarlo de cualquier forma (por ejemplo MiTipo Maximo<MiTipo>(MiTipo uno, MiTipo otro)), aunque ceñirse a las convenciones de codificación es normalmente una buena idea.

A continuación, podemos observar que los dos parámetros de entrada son del tipo T, así como el retorno de la función. Si no lo ves claro, sustituye mentalmente la letra T por int (por ejemplo) y seguro que mejora la cosa.

Lógicamente, estos métodos pueden presentar un número indeterminado de parámetros genéricos, como en el siguiente ejemplo:

  public TResult MiMetodo<T1, T2, TResult>(T1 param1, T2 param2)
  {
      // ... cuerpo del método
  }

Restricciones en parámetros genéricos

Retomemos un momento el código de nuestro método genérico Maximo:

  public T Maximo<T>(T uno, T otro) where T: IComparable
  {
    if (uno.CompareTo(otro) > 0) return uno;
    return otro;
  }

Vamos a centrarnos ahora en la porción final de la firma del método anterior, donde encontramos el código where T: IComparable. Se trata de una restricción mediante la cual estamos indicando al compilador que el tipo T podrá ser cualquiera, siempre que implementente el interfaz IComparable, lo que nos permitirá realizar la comparación.

Existen varios tipos de restricciones que podemos utilizar para limitar los tipos permitidos para nuestros métodos parametrizables:

where T: struct, indica que el argumento debe ser un tipo valor.
where T: class, indica que T debe ser un tipo referencia.
where T: new(), fuerza a que el tipo T disponga de un constructor público sin parámetros; es útil cuando desde dentro del método se pretende instanciar un objeto del mismo.
where T: nombredeclase, indica que el argumento debe heredar o ser de dicho tipo.
where T: nombredeinterfaz, el argumento deberá implementar el interfaz indicado.
where T1: T2, indica que el argumento T1 debe ser igual o heredar del tipo, también argumento del método, T2.

Un último detalle relativo a esto: a un mismo parámetro se pueden aplicar varias restricciones, en cuyo caso se separarán por comas, como aparece en el siguiente ejemplo:

  public TResult MiMetodo<T1, T2, TResult>(T1 param1, T2 param2)
    where TResult: IEnumerable
    where T1: new(), IComparable
    where T2: IComparable, ICloneable
    {
        // ... cuerpo del método
    }

En cualquier caso, las restricciones no son obligatorias. De hecho, sólo debemos utilizarlas cuando necesitemos restringir los tipos permitidos como parámetros genéricos, como en el ejemplo del método Maximo<T>, donde es la única forma que tenemos de asegurarnos que las instancias que nos lleguen en los parámetros puedan ser comparables.

Uso de métodos genéricos

  string mazinger = Maximo<string>("Mazinger", "Afrodita");  
  int i99 = Maximo<int>(2, 99);

  string mazinger = Maximo("Mazinger", "Afrodita");  
  int i99 = Maximo(2, 99);

El compilador deduce el tipo del método genérico a partir de los que estamos utilizando en la lista de parámetros. Por ejemplo, en el primer caso, dado que los dos parámetros son string, puede llegar a la conclusión de que el método tiene una signatura equivalente a string Maximo(string, string), que coincide con la definición del genérico.

Otro ejemplo de método genérico

Veamos un ejemplo un poco más complejo. El método CreaLista, aplicable a cualquier clase, retorna una lista genérica (List<T>) del tipo parametrizado del método, que rellena inicialmente con los argumentos (variables) que se le suministra:

  public List<T> CreaLista<T>(params T[] pars)
  {
    List<T> list = new List<T>();
    foreach (T elem in pars)
    {
      list.Add(elem);
    }
    return list;
  }

  // ...
  // Uso:
  List<int> nums = CreaLista<int>(1, 2, 3, 4, 6, 7);
  List<string> noms = CreaLista<string>("Pepe", "Juan", "Luis");

Otros ejemplos de uso, ahora beneficiándonos de la inferencia de tipos:

  List<int> nums = CreaLista(1, 2, 3, 4, 6, 7);
  List<string> noms = CreaLista("Pepe", "Juan", "Luis"); 

  // Incluso con tipos anónimos de C# 3.0:
  var p = CreaLista(
            new { X = 1, Y = 2 }, 
            new { X = 3, Y = 4 }
          );
  Console.WriteLine(p[1].Y); // Pinta "4"

En resumen, se trata de una característica de la plataforma .NET, reflejada en lenguajes como C# y VB.Net, que está siendo ampliamiente utilizada en las últimas incorporaciones al framework, y a la que hay que habituarse para poder trabajar eficientemente con ellas.

Publicado en: www.variablenotfound.com.

Cómo convertir clases en diccionarios clave/valor

José M. Aguilar — Sun, 16 Nov 2008 22:40:00 GMT

El otro día, a raíz del post Atajo para instanciar tipos anónimos en C# y VB.NET, el amigo Leo H., desde Argentina, me envió una cuestión:

[...] Me parece muy interesante crear diccionarios utilizando tipos anónimos, pues simplifica de una forma considerable la cantidad de código que hay que escribir para conseguir llenar una estructura de este tipo. De hecho, estoy pensando en utilizar esta técnica en una librería que estoy desarrollando, pero no veo claro cómo transformar después ese objeto anónimo en el diccionario equivalente [...]

Verás que la idea es muy simple. Sólo necesitamos encontrar una fórmula que nos permita recorrer las propiedades del objeto, y por cada una de ellas, añadir la entrada correspondiente en el diccionario, especificando como clave el nombre de la propiedad y como valor el que tenga establecido la misma.

Una posibilidad muy sencilla es usar la clase TypeDescriptor, cuyo método GetProperties() nos devuelve una colección con los descriptores de las propiedades de la instancia que le pasemos como parámetro. Iterando sobre este conjunto, podremos ir llenando el diccionario con los elementos que nos interese, tal que así, dado un objeto llamado obj:

  Dictionary<string, object> dicc = new Dictionary<string, object>();
  foreach (PropertyDescriptor desc in TypeDescriptor.GetProperties(obj))
  {
    dicc.Add(desc.Name, desc.GetValue(obj));
  }

Pero vamos a dar una vuelta de tuerca más. Partiendo del código anterior, es muy fácil crear un método de extensión sobre la clase object, de forma que podamos convertir en un diccionario cualquier objeto de nuestras aplicaciones, con toda la potencia y comodidad que nos aporta esta técnica.

El código sería:

  public static class Extensions
  {
    public static Dictionary<string, object> ToDictionary(this object obj)
    {
      Dictionary<string, object> dicc = new Dictionary<string, object>();
      foreach (PropertyDescriptor desc in TypeDescriptor.GetProperties(obj))
      {
        dicc.Add(desc.Name, desc.GetValue(obj));
      }
      return dicc;
    }
  }

De esta forma, dispondremos de una potente forma de "diccionarizar" nuestras instancias, sean del tipo que sean, por ejemplo:


  var juan = new { nombre = "Juan", edad = 23 };
  Dictionary<string, object> dicc = juan.ToDictionary();  
  Console.WriteLine(dicc["nombre"]); // Escribe "Juan"

  var dicc2 = "hola".ToDictionary();
  Console.WriteLine(dicc2["Length"]);  // Escribe 4

Espero que te sea de ayuda, Leo. ¡Y gracias por participar en Variable Not Found!

Publicado en: www.variablenotfound.com.

Intellisense completo para jQuery en Visual Studio 2008

José M. Aguilar — Sun, 09 Nov 2008 21:59:00 GMT

Semanas atrás, Microsoft adelantaba en el anuncio de la inclusión de jQuery en la plataforma de desarrollo de la compañía, que pronto dispondríamos de soporte total de intellisense para jQuery, y ya podemos ver el resultado.

Por una parte, a finales del pasado mes de octubre se publicó en el sitio de descargas de jQuery, y apareció enlazado desde su propia web oficial, el archivo de anotaciones que permite el disfrute de la experiencia intellisense en todo su esplendor mientras utilizamos la librería desde Visual Studio 2008: información completa sobre los métodos que estamos usando, parámetros, valores de retorno, y autocompletado de escritura. Una gozada, vaya.

Y aunque pueda parecer lo contrario por su extensión (se trata de un archivo .js), es sólo eso, un archivo de documentación, no una sustitución para la librería original. De hecho, si queremos utilizar jQuery en nuestros proyectos y disfrutar del intellisense, deberemos incluir tanto el archivo original de la librería (en este momento versión 1.2.6) como el de anotaciones, denominado denominado jquery-1.2.6-vsdoc.js.

Por otra parte, sólo unos días después, Microsoft ha publicado el hotfix KB958502 para Visual Studio 2008 Service Pack 1 (y válido también para Visual Web Developer Express SP1) que hace que el entorno sea capaz de buscar automáticamente los archivos de documentación relativos a cada librería javascript que estemos utilizando, y tomar de ellos la información para activar intellisense. De hecho, por cada archivo javascript referenciado desde nuestro código con un nombre "xxx.js", el entorno buscará la documentación en el archivo "xxx-vsdocs.js"; si no la encuentra, probará con "xxx.debug.js", y si tampoco hay nada, dentro de la propia librería "xxx.js".

Por tanto, una vez instalado este parche, si estás utilizando jQuery directamente sobre una página .ASPX, algo muy habitual, basta con descargar el archivo de anotaciones e incluirlo en el directorio de scripts del proyecto para que la magia intellisense comience a funcionar en todas las páginas en las que exista una referencia hacia jQuery (un tag <script src="...">), o que se basen en una página maestra que incluya dicha referencia.

Si estás editando un fichero javascript (.js) en Visual Studio y desde él quieres utilizar jQuery con intellisense, puedes utilizar un comentario con la etiqueta Reference, que indica al entorno que puede tomar la documentación de los archivos indicados en la misma. Basta con encabezar el archivo .js así:

  /// <reference path="jquery-1.2.6-vsdoc.js">

El comentario, obviamente, no afecta a la ejecución, y sólo es interpretado por el IDE para buscar referencias a archivos de documentación.

Por último, como apunta Jeff King, Program Manager en el equipo de herramientas para la Web de Visual Studio, es conveniente aclarar que el objetivo de este parche no es únicamente dar soporte a jQuery; se trata de una solución general para facilitar la integración de documentación de librerías javascript en el entorno de desarrollo, y que seguro vamos a poder aprovechar en muchas otras ocasiones.

Publicado en: www.variablenotfound.com.

Atajo para instanciar tipos anónimos en C# y VB.NET

José M. Aguilar — Sun, 02 Nov 2008 22:59:00 GMT

Tanto la guía de programación del lenguaje C# 3.0 como la de Visual Basic .NET 9 hablan de que ambos compiladores pueden agilizar la instanciación de tipos anónimos, permitiendo escribir instrucciones realmente concisas, gracias a su capacidad para deducir los nombres de las propiedades a partir de su contexto. Sin embargo son ese tipo de detalles que, al menos un servidor, había pasado por alto a pesar de haberlo visto utilizado más de una vez.

Como sabemos, la creación "normal" de un objeto de tipo anónimo es como sigue, si lo que queremos es inicializar sus propiedades con valores constantes:

  // C#
  var o = new { Nombre="Juan", Edad=23 };

  ' VB.NET
  Dim o = New With { .Nombre="Juan", .Edad=23 }

Sin embargo, muchas veces vamos a inicializar sus miembros con valores tomados de variables o parámetros visibles en el lugar de la instanciación, por ejemplo:

  // C#
  public void hacerAlgo(string nombre, int edad)
  {
    var o = new { nombre=nombre, edad=edad };
    ...
  }

  ' VB.NET
  Public Sub HacerAlgo(ByVal nombre As String, _
                       ByVal edad As Integer)
    Dim o = New With {.nombre = nombre, .edad = edad}
    ... 
  End Sub

Pues bien, es justo en estos casos cuando podemos utilizar una sintaxis más compacta, basada en la capacidad de los compiladores de inferir el nombre de las propiedades del tipo anónimo partiendo de los identificadores de las variables que utilicemos en su inicialización. O en otras palabras, el siguiente código es equivalente al anterior:

  // C#
  public void hacerAlgo(string nombre, int edad)
  {
    var o = new { nombre, edad };
    ...
  }

  ' VB.NET
  Public Sub HacerAlgo(ByVal nombre As String, _
                       ByVal edad As Integer)
    Dim o = New With {nombre, edad}
    ... 
  End Sub

Brad Wilson, un desarrollador del equipo ASP.NET de Microsoft, nos ha recordado hace unos días lo bien que viene este atajo para la instanciación de tipos anónimos utilizados para almacenar diccionarios clave/valor, como los usados en el framework ASP.NET MVC. También es una característica muy utilizada en Linq para el retorno de tipos anónimos que contienen un subconjunto de propiedades de las entidades recuperadas en una consulta.

Publicado en: www.variablenotfound.com.

Plantillas de proyectos de tests NUnit para ASP.NET MVC Preview 3

José M. Aguilar — Mon, 30 Jun 2008 19:56:00 GMT

La inclusión en el SP1 (Beta) de Visual Web Developer Express 2008 de soporte para librerías de clases y aplicaciones Web, abriendo el uso del framework MVC Preview 3 para los que estamos aprendiendo con esta herramienta, era sin duda una novedad sorprendente, pero no la única.

Joe Cartano comentaba hace unas semanas, en el blog oficial del equipo de Visual Web Developer , las nuevas mejoras de este IDE, y en especial las relativas al soporte para plantillas de terceros, y publicó de paso unas estupendas plantillas para la creación de tests unitarios basados en NUnit en aplicaciones ASP.NET MVC.

Para instalarlas, basta con descargar el archivo (con el enlace anterior), descomprimirlo sobre un directorio cualquiera y ejecutar el archivo .BAT correspondiente a la versión de Visual Studio que estemos utilizado, siempre con permisos de administrador. Si todo va bien y suponiendo además que tenemos NUnit instalado, al crear una nueva aplicación ASP.NET MVC en VWD Express aparecerá un cuadro de diálogo como el siguiente:

Esto va en la línea de lo comentado por ScottGu meses atrás, en sus primeros posts sobre el nuevo framework MVC, donde aseguraba que se podría utilizar cualquier framework de testing, citando algunos como NUnit y MBUnit. Y lo de permitir una cierta integración de estos frameworks ajenos a la casa en la versión Express es todo un detalle.

Si se acepta el diálogo, se creará dentro de la misma solución un proyecto de tipo librería que contendrá las referencias a ensamblados necesarios para su ejecución (NUnit, routing, Mvc, etc.) y con un par de métodos de prueba predefinidos. De esta forma, para comprobar el correcto funcionamiento de nuestras aplicaciones sólo tendremos que ejecutar los tests, aunque de momento, y a diferencia de las versiones superiores de Visual Studio 2008, tendrá que ser desde fuera del entorno, utilizando la consola de NUnit:

Publicado en: www.variablenotfound.com.

ASP.NET MVC Preview 3, por fin para Visual Web Developer Express

José M. Aguilar — Mon, 23 Jun 2008 21:09:00 GMT

Cuando hace unas semanas ScottGu anunció la Preview 3 de ASP.NET MVC, quedé muy sorprendido de que al final no viniera con soporte para Visual Web Developer Express 2008, sobre todo teniendo en cuenta que un mes antes había adelantado este acontecimiento para los que estamos probando la plataforma MVC con esta herramienta.

Pero no, era una falsa alarma. Scott había olvidado comentarlo, y días más tarde rectificaba en un nuevo post en el que comunicaba que sí sería posible usar la Preview 3 desde la versión Express de Web Developer sin necesidad de usar plantillas específicas.

Desde entonces estaba deseando tener un ratillo para probarlo, y por fin ha llegado el momento.

En primer lugar, he de aclarar que, aunque pueda parecer lo contrario, no se trata de que el equipo de Microsoft haya introducido cambios en la plataforma MVC para hacerla compatible con la versión Express, sino al revés. Son los nuevos cambios introducidos en el IDE, y principalmente su recién estrenado soporte a proyectos de tipo Aplicación Web, los que hacen posible que funcione directamente sobre esta herramienta.

Y este es el motivo de que, antes que nada, sea necesario instalar el SP1 de .NET Framework 3.5 y de las herramientas Express (aún en Beta). Y si váis a hacerlo, mucho ojo, que todas las páginas donde aparece para descargar aparece llena de warnings; en otras palabras, no recomiendan su instalación en máquinas de verdad, sólo en entornos de prueba. Pero no os preocupéis, que para eso estoy yo ;-)

Después de un proceso algo lento y un par de reinicios del equipo, el Service Pack 1 Beta queda instalado sin problemas. Sólo falta descargar y montar la Preview 3 de ASP.NET MVC para que al ir a crear un nuevo proyecto desde Visual Web Developer aparezcan la plantilla MVC, entre otras novedades:

Y para probar, nada mejor que la aplicación de demostración sobre Northwind que preparó Phil Haack hace unas semanas. Salvo un ligero error de carga debido a que la versión Express no soporta la creación de proyectos de solución (no podremos probar los tests unitarios integrados en VS2008), todo funciona a la perfección.

Sí señor. Ahora sí que podemos seguir jugando. :-)

Publicado en: www.variablenotfound.com.

Disponible Microsoft Source Analysis for C#

José M. Aguilar — Sat, 24 May 2008 10:51:00 GMT

Jason Allor anunciaba ayer mismo el lanzamiento de una nueva herramienta, Microsoft Source Analysis for C#, cuyo objetivo es ayudar a los desarrolladores a producir código elegante, legible, mantenible y consistente entre los miembros de un equipo de trabajo. De hecho, era conocida como StyleCop en Microsoft, donde llevan utilizándola ya varios años.

Y aunque pueda parecer similar a FxCop, Microsoft Source Analysis for C# se centra en el análisis de código fuente y no en ensamblados, lo que hace que pueda afinar mucho más en las reglas de codificación.

Incluye sobre 200 buenas prácticas, cubriendo aspectos como:

Layout (disposición) de elementos, instrucciones, expresiones y consultas
Ubicación de llaves, paréntesis, corchetes, etc.
Espaciado alrededor de palabras clave y operadores
Espaciado entre líneas
Ubicación de parámetros en llamadas y declaraciones de métodos
Ordenación de elementos de una clase
Formateo de documentación de elementos y archivos
Nombrado de campos y variables
Uso de tipos integrados
Uso de modificadores de acceso
Contenidos permitidos en archivos
Texto de depuración

Tras su descarga e instalación, que puede realizarse desde esta dirección, la herramienta se integra en Visual Studio 2005 y 2008, aunque también puede utilizarse desde la línea de comandos o MSBuild.

Publicado en: www.variablenotfound.com.

Inicializadores de colecciones en C#

José M. Aguilar — Mon, 28 Apr 2008 18:22:00 GMT

Días atrás hablaba de las formas de inicialización de objetos que nos proporcionaban las últimas versiones de C# y VB.Net, que permitían asignar valores a miembros de instancia de forma muy compacta, legible y cómoda.

C# 3.0 nos trae otra sorpresa, también relacionada con el establecimiento de valores iniciales de elementos: los inicializadores de colecciones. Aunque esta característica también estaba prevista para VB.Net 9.0, al final fue desplazada a futuras versiones por problemas de tiempo.

Para inicializar una colección, hasta ahora era necesario en primer lugar crear la clase correspondiente para, a continuación, realizar sucesivas invocaciones al método Add() con cada uno de los elementos a añadir:

 List<string> ls = new List<string>();
 ls.Add("Uno");
 ls.Add("Dos");
 ls.Add("Tres");

C# 3.0 permite una alternativa mucho más elegante y rápida de codificar, simplemente se introducen los elementos a añadir a la colección entre llaves (como se hacía con los inicializadores de arrays o los nuevos inicializadores de objetos), separados por comas, como en el siguiente ejemplo:

 List<string> ls = 
     new List<string>() { "Uno", "Dos", "Tres" };

Si desensamblamos el ejecutable resultante, podremos ver que es el compilador el que ha añadido por nosotros los Add() de cada uno de los elementos después de instanciar la colección:


 newobj   instance void class 
          [mscorlib]System.Collections.Generic.List`1<string>::.ctor()
 stloc.s  '<>g__initLocal0'
 ldloc.s  '<>g__initLocal0'
 ldstr    "Uno"
 callvirt instance void class 
          [mscorlib]System.Collections.Generic.List`1<string>::Add(!0)
 nop
 ldloc.s  '<>g__initLocal0'
 ldstr    "Dos"
 callvirt instance void class 
          [mscorlib]System.Collections.Generic.List`1<string>::Add(!0)
 nop
 ldloc.s  '<>g__initLocal0'
 ldstr    "Tres"
 callvirt instance void class 
          [mscorlib]System.Collections.Generic.List`1<string>::Add(!0)
 nop

Uniendo esto ahora con los inicializadores de objetos que ya tratamos un post anterior, fijaos en la potencia del resultado:

 List<Persona> lp = new List<Persona>
 {
   new Persona { Nombre="Juan", Edad=34 },
   new Persona { Nombre="Luis", Edad=53 },
   new Persona { Nombre="José", Edad=23 }
 };

Efectivamente, cada elemento es una nueva instancia de la clase Persona, con las propiedades que nos interesan inicializadas de forma directa. De hacerlo con los métodos tradicionales, para conseguir el mismo resultado deberíamos utilizar muuuchas más líneas de código.

Otro ejemplo que demuestra aún más la potencia de esta característica:

 var nums = new SortedList
 {
   { 34, "Treinta y cuatro" },
   { 12, "Doce" },
   { 3, "Tres" }
 };
 foreach (var e in nums)
   Console.WriteLine(e.Key + " " + e.Value);

En el código anterior podemos ver, primero, el uso de variables locales de tipo implícito, para ahorrarnos tener que escribir más de la cuenta. En segundo lugar, se muestra cómo se inicializa una colección cuyo método Add() requiere dos parámetros. En el caso de un SortedList<TKey, TValue>, su método Add() requiere la clave de ordenación y el valor del elemento.

(Obviamente, el resultado de la ejecución del código anterior será la lista ordenada por su valor numérico (Key))

En conclusión, se trata de otra de las innumerables ventajas que nos ofrece la nueva versión de C# destinadas a evitarnos pulsaciones innecesarias, y a la que seguro le daremos uso.

Publicado en: www.variablenotfound.com.

Efectos laterales en métodos parciales

José M. Aguilar — Wed, 16 Apr 2008 19:04:00 GMT

Hace unos días comentaba que el uso de métodos parciales puede causar algunos problemas en la ejecución de nuestras aplicaciones que podríamos calificar, cuanto menos, de "incómodos".

Recordemos que una parte de una clase parcial puede declarar un método y utilizarlo (invocarlo) dentro de su código; si el método está implementado en otro fragmento de la clase, se ejecutará como siempre, pero si no ha sido implementado, el compilador eliminará tanto la declaración del método como las llamadas que se hagan al mismo.

Sin embargo esta eliminación pueden causar efectos no deseados difíciles de detectar.

Veámoslo con un ejemplo. Supongamos una clase parcial como la siguiente, que representa a una variable de tipo entero que puede ser incrementada o decrementada a través de métodos:

 public partial class Variable
 {
   partial void Log(string msg);
   private int i = 0;

   public void Inc()
   {
      i++;
      Log("Incremento. I: " + i);
   }

   public void Dec()
   {
      Log("Decremento. I: " + (--i));
   }

   public int Value
   {
     get { return i; }
   }
 }

Creamos ahora un código que utiliza esta clase de forma muy simple: crea una variable, la incrementa dos veces, la decrementa una vez y muestra el resultado:

 Variable v = new Variable();
 v.Inc();
 v.Inc();
 v.Dec();
 Console.WriteLine(v.Value);

Obviamente, tras la ejecución de este código la pantalla mostrará por consola un "1", ¿no? Claro, el resultado de realizar dos incrementos y un decremento sobre el cero.

Pues no necesariamente. De hecho, es imposible conocer, a la vista del código mostrado hasta ahora, cuál será el resultado mostrado por consola al finalizar la ejecución. Dependiendo de la existencia de la implementación del método parcial Log(), declarado e invocado en la clase Variable anterior, puede ocurrir:

Si existe otra porción de la misma clase (otra partial class Variable) donde se implemente el método, se ejecutará éste. El valor mostrado por consola, salvo que desde esta implementación se modificara el valor del campo privado, sería "1".
Si no existe una implementación del método Log() en la clase, el compilador eliminará todas las llamadas al mismo. Pero si observáis, esto incluye el decremento del valor interno, que estaba en el interior de la llamada como un autodecremento:
```
Log("Decremento. I: " + (--i));
```
Por tanto, en este caso, el compilador eliminará tanto la llamada a Log() como la operación que se realiza en el interior. Obviamente, el resultado de ejecución de la prueba anterior sería "2".

Lo mismo ocurriría si el resultado a mostrar fuera el valor de retorno de una llamada a otra función: esta no se ejecutaría, lo cual puede ser grave si en ella se realiza una operación importante, como por ejemplo:
```
public function InicializaValores()
{
   Log("Elementos reestablecidos: " + reseteaElementos() );
}
```

Conclusión: usad los métodos parciales siempre con precaución, pues podemos introducir errores muy difíciles de detectar y corregir, sobre todo por falta aparente de relación entre causa y efecto.

Por ejemplo, imaginad que el ejemplo anterior contiene una implementación de Log(); la aplicación funcionaría correctamente. Sin embargo, si pasado un tiempo se decide eliminar esta implementación (por ejemplo, porque ya no es necesario registrar las operaciones realizadas), la operación de decremento (Dec()) dejaría de funcionar.

Aunque, eso sí, no es nada que no se pueda solucionar con un buen juego de pruebas...

Publicado en: http://www.variablenotfound.com/.

Métodos parciales en C# 3 y VB.NET 9

José M. Aguilar — Sun, 13 Apr 2008 19:13:00 GMT

Una vez visto el concepto de las clases parciales, ya es posible profundizar en los métodos parciales, una característica aparecida en las nuevas versiones de los lenguajes estrella de Microsoft, C# y VB.Net.

Estos métodos, declarados en el contexto de una clase parcial, permiten comunicar de forma segura los distintos fragmentos de dicha clase. De forma similar a los eventos, permiten que un código incluya una llamada a una función que puede (o no) haber sido implementada por un código cliente, aunque en este caso obligatoriamente la implementación se encontrará en uno de los fragmentos de la misma clase desde donde se realiza la llamada.

En la práctica significa que una clase parcial puede declarar un método y utilizarlo (invocarlo) dentro de su código; si el método está implementado en otro fragmento de la clase, se ejecutará como siempre, pero si no ha sido implementado, el código correspondiente a la llamada será eliminado en tiempo compilación para optimizar el resultado... ¡sí, eliminado!

Por ejemplo, el siguiente código muestra una declaración de un método parcial en el interior de una clase, y su utilización desde dentro de uno de sus métodos:

 // C#
 public partial class Ejemplo
 {
      
   // El método parcial se declara
   // sin implementación...
   partial void Log(string msg);

   public void RealizarAlgo()
   {
     hacerAlgoComplejo();
     Log("¡Ojo!"); // Usamos el método
                   // parcial declarado antes
   }
   
   [...] // Otros métodos y propiedades

 }

 ' VB.NET
 Partial Public Class Ejemplo

   ' El método parcial se declara, sin
   ' implementar nada en el cuerpo
   Partial Private Sub Log(ByVal msg As String)
   End Sub

  Public Sub RealizarAlgo()
    HacerAlgoComplejo()
    Log("¡Ojo!") ' Usamos el método parcial
  End Sub

  [...] ' Otros métodos y propiedades
 End Class

Y esta la parte realmente curiosa. Cuando el compilador detecta la invocación del método parcial Log(), buscará en todos los fragmentos de la clase a ver si existe una implementación del mismo. Si no existe, eliminará del ensamblado resultante la llamada a dichos métodos, es decir, actuará como si éstas no existieran en el código fuente.

En caso afirmativo, es decir, si existen implementaciones como las del siguiente ejemplo, todo se ejecutará conforme a lo previsto:

 // C#
 public partial class Variable
 {
   partial void Log(string msg)
   {
     Console.WriteLine(msg);
   }
 }

 ' VB.Net
 Partial Public Class Variable
   Private Sub Log(ByVal msg As String)
     Console.WriteLine(msg)
   End Sub
 End Class

Antes comentaba que los métodos parciales son, en cierto sentido, similares a los eventos, pues conceptualmente permiten lo mismo: pasar el control a un código cliente en un momento dado, en el caso de que éste exista. De hecho, hay muchos desarrolladores que lo consideran como un sustituto ligero a los eventos, pues permite prácticamente lo mismo pero se implementan de forma más sencilla.

Existen, sin embargo, algunas diferencias entre ambos modelos, como:

Los métodos parciales se implementan en la propia clase, mientras que los eventos pueden ser consumidos también desde cualquier otra
El enlace, o la suscripción, a eventos es dinámica, se realiza en tiempo de ejecución, es necesario incluir código para ello; los métodos parciales, sin embargo, se vinculan en tiempo de compilación
Los eventos permiten múltiples suscripciones, es decir, asociarles más de un código cliente
Los eventos pueden presentar cualquier visibilidad (pública, privada...), mientras que los métodos parciales son obligatoriamente privados.

También puede verse como algo parecido a la herencia en una jerarquía de clases. Una clase puede incluir un método virtual vacío y utilizarlo en su implementación, y si una clase hija sobreescribe el mismo, ésta se ejecutará en su lugar. Pero claro, hay que tener en cuenta que el ámbito de consumo del método parcial es la misma clase donde se declara e implementa.

Por último, es conveniente citar algunas consideraciones sobre los métodos parciales:

Deben ser siempre privados (ya lo había comentado antes)
No deben devolver valores (en VB.Net serían SUB, en C# serían de tipo void)
Pueden ser estáticos (shared en VB)
Pueden usar parámetros, acceder a los miembros privados de la clase... en definitiva, actuar como un método más de la misma

En resumen, los métodos parciales forman parte del conjunto de novedades de C# y VB.Net que no son absolutamente necesarias y que a veces pueden parecer incluso diabólicas, pues facilitan la dispersión de código y dificultan la legibilidad. Además, en breve publicaré un post comentando posibles efectos laterales a tener en cuenta cuando usemos los métodos parciales en nuestros desarrollos.

Sin embargo, es innegable que los métodos parciales nos facilitan enormemente la inclusión de código de usuario en el interior de clases generadas de forma automática. Por ejemplo, el diseñador visual del modelo de datos de LinqToSQL genera los DataContext como clases parciales, en las que define un método parcial llamado OnCreated(). Si el usuario quiere incluir alguna inicialización personal al crear los DataContext, no tendrá que tocar el código generado de forma automática; simplemente creará otro fragmento de la clase parcial e implementará este método, de una forma mucho más natural y cómoda que si se tratara de un evento.

Publicado en: http://www.variablenotfound.com/.

Inicialización rápida de objetos en C# 3.0 y VB.Net 9.0

José M. Aguilar — Mon, 03 Mar 2008 19:57:00 GMT

Como ya venimos comentando hace tiempo, la nueva versión de ambos lenguajes viene repleta de novedades y mejoras pensadas para hacernos la vida más fácil y, por tanto, aumentar la productividad de los desarrolladoradores. Bueno, no sé si fue así o en realidad es que simplemente eran necesarias para Linq y por eso fueron incluidas ;-), pero el caso es que a partir de las versiones 3.0 y 9.0 de C# y VB.NET respectivamente, tenemos a nuestra disposición interesantísimas herramientas que deberíamos conocer para sacar el máximo provecho a nuestro tiempo.

En esta ocasión vamos a centrarnos en los inicializadores de objetos, una nueva característica destinada, entre otras cosas, a ahorrarnos tiempo a la hora de establecer los valores iniciales de los objetos que creemos desde código.

Y es que, hasta ahora, podíamos utilizar dos patrones básicos de inicialización de propiedades al instanciar una clase:

que fuera la clase la que realizara esta tarea, ofreciendo al usuario de la misma constructores con distintas sobrecargas cuyos parámetros corresponden con las propiedades a inicializar.

// Constructor de la clase Persona:
public Persona(string nombre, string apellidos, int edad, ...)
{
   this.Nombre = nombre;
   this.Apellidos = apellidos;
   this.Edad = edad;
   ...
}
// Uso:
Persona p = new Persona("Juan", "López", 32, ...);

o bien dejar esta responsabilidad al usuario, permitiéndole el acceso directo a propiedades o campos del objeto creado.
```
// Uso:
Persona p = new Persona();
p.Nombre = "Juan";
p.Apellidos = "López";
p.Edad = 32;
...
```

Cualquiera de las dos formas anteriores, así como de opciones intermedias que combinen ambas ideas, tiene sus ventajas e inconvenientes, pero son igualmente tediosas. Si hablamos de clases con un gran número de propiedades, la cantidad de líneas de código necesarias para realizar una inicialización son realmente importantes.

Los inicializadores de objetos permiten, en C# y VB.Net, realizar esta tarea de forma más simple, simplemente indicando en la llamada al constructor el valor de las propiedades o campos que deseemos establecer:
// C#: Persona p = new Persona { Nombre="Juan", Apellidos="López", Edad=32 };

' VB.NET: Dim p = New Persona With {.Nombre="Luis", .Apellidos="López", .Edad=32 }

Los ejemplos anteriores son válidos para clases que admitan constructores sin parámetros, pero, ¿qué ocurre con los demás? Imaginando que el constructor de la clase Persona recibe obligatoriamente dos parámetros, su nombre y apellidos, podríamos instanciar así:

// C#:
Persona p = new Persona ("Luis", "López") { Edad = 32 };


' VB.NET:
Dim p = New Persona ("Luis", "López") With { .Edad = 32 }

Aunque es obvio, es importante tener en cuenta que las inicializaciones (la porción de código entre llaves "{" y "}") se ejecutan después del constructor:

// C#: Persona p = new Persona ("Juan", "Pérez") { Nombre="Luis" }; Console.WriteLine(p.Nombre); // Escribe "Luis" ' VB.NET: Dim p = New Persona ("Juan", "Pérez") With { .Nombre="Luis" } Console.WriteLine(p.Nombre); ' Escribe "Luis"

Y un último apunte: ¿cómo inicializaríamos propiedades de objetos que a su vez sean objetos que también queremos inicializar? Suponiendo que en nuestra clase Persona hemos incluido una propiedad llamada Domicilio que de tipo Localizacion, podríamos inicializar el bloque completo así:
// C#: // Se han cortado las líneas para facilitar la lectura Persona p = new Persona() { Nombre = "Juan", Apellidos = "López", Edad = 55, Domicilio = new Localizacion { Direccion = "Callejas, 34", Localidad = "Sevilla", Provincia = "Sevilla" } }; ' VB.NET: ' Se han cortado las líneas para facilitar la lectura Dim p = New Persona() With { _ .Nombre = "Juan", _ .Apellidos = "López", _ .Edad = 55, _ .Domicilio = New Localizacion With { _ .Direccion = "Callejas, 23", _ .Localidad = "Sevilla", _ .Provincia = "Sevilla" _ } _ }
En fin, que de nuevo tenemos ante nosotros una característica de estos lenguajes que resulta interesante por sí misma, aunque toda su potencia y utilidad podremos percibirla cuando profundicemos en otras novedades, como los tipos anónimos y Linq... aunque eso será otra historia.

Publicado en: http://www.variablenotfound.com/.