Espada afilada

La prima de un amigo de mi cuñada

Según una popular leyenda urbana, entre usted y cualquier otra persona, sin importar el país de esta última, existe una cadena de conocidos que es sorprendentemente corta: usted conoce a Fulano, quien a su vez conoce a Mengano, el primo de Zutano, aquel que es amigo de la peluquera de Drew Barrymore. La longitud de la cadena, por supuesto, depende de quién cuente la historia. En todo caso, es una leyenda en la que creo. ¿Qué tal siete eslabones?

¿Y si este fenómeno tuviese en parte la culpa de que las bases de datos orientadas a objetos no hayan prosperado como predecía la teoría? Podrían combinarse negativamente dos factores:

1. Por una parte, estaría lo que acabo de explicar: que en la mayoría de los esquemas de datos, hay tanta imbricación que, un sistema de bases de datos orientado a objetos implementado ingenuamente, podría saturar en muy poco tiempo la memoria dinámica, trayendo a ésta casi todos los registros.
2. En principio, habría técnicas para evitar esto, utilizando carga por demanda... pero, ¿se da cuenta de que estamos hablando de clases y objetos, y por lo tanto, de encapsulación? Si enredamos demasiado con las relaciones estructurales, entraremos en conflicto con la encapsulación.

No estoy diciendo que ésta, en concreto, sea la única causa, ni la principal. Se me ha ocurrido esta posibilidad mientras pensaba en los pros y contras de un sistema como LINQ: me parece que el principal y casi seguro logro de LINQ va a ser que dispondremos de unos datasets estupendos, aunque no los llamemos así en lo sucesivo. Habrá que esperar a la implementación de los árboles de expresiones para ver qué tal se comporta la recuperación de registros desde un servidor SQL: como, de todas maneras, el servidor SQL optimizará la consulta recibida, es casi seguro que, incluso en el peor de los escenarios, funcione bien. Y todo esto es bueno y deseable. Pero nada de esto no nos acerca a las bases de datos orientadas a objetos. Y puede que esto último también sea bueno y deseable.

---

Corolario: Entre usted y los extraterrestres hay al menos una cadena de ocho eslabones.

Demostración: Entre usted y Drew Barrymore hay una cadena de no más de siete eslabones. Y Drew Barrymore conoce a E.T.

En el radar

Próxima actualización en el radar: nueva entrega de Intuitive C#. Hay un nuevo capítulo sobre P.O.O. (el segundo), que no cuenta nada nuevo, pero lo que cuenta está más o menos bien escrito. O eso creo. Hay más información sobre reflexión, tipos de interfaz, genericidad, inferencia de tipos en llamadas a métodos genéricos, expresiones lambda (¡sí, las de C# 3.0!), qué es una restricción desnuda y cómo puede usarse para simular la covarianza en la asignación polimórfica de tipos genéricos, convirtiendo, por ejemplo, una lista de empleados en una lista de personas (y provocando una excepción cuando encuentre un abogado en ella)...

No, todavía no lo he subido a Internet. Ya avisaré, probablemente el lunes que viene.

---

Un comentario breve sobre C# 3.0: no me gusta la forma de "activar" los métodos de extensión. Esto ya lo tenía Delphi.NET 8.0: podías fingir que una clase ajena tenía métodos adicionales definiendo esos nuevos métodos como métodos estáticos cuyo primer parámetro tenga el tipo de la clase a extender. Así, Borland intentaba acercar el System.Object de .NET con el TObject délfico de siempre.

En Freya ya hay unas pocas extensiones predefinidas. Por ejemplo, hay dos extensiones que se expanden en línea: los "métodos" Sqr, que actúa sobre tipos numéricos, y Ord, que convierte caracteres en su valor numérico Unicode:

Console.WriteLine(2.Sqr);

El compilador genera código muy eficiente para Sqr: una instrucción de duplicación y la multiplicación. En una aplicación como XSight RT, donde hay que elevar expresiones complejas al cuadrado constantemente, no sólo queda más legible el código fuente, sino que además, se genera mejor código nativo, y el compilador JIT tiene menos carga y termina antes, al serle más sencillo identificar el patrón. Aparte de esto, se considera que todos los métodos estáticos de la clase System.Math se registran automáticamente como métodos de extensión. Así podemos escribir lo siguiente en Freya:

var L := (X.Sqr + Y.Sqr + Z.Sqr).Sqrt;
if (L - L0).Abs < epsilon then
    // ...

Lo que no me gusta es la forma en que se "activan" los métodos de extensión en C#: basta con incluir el espacio de nombres en una cláusula using, para que todos los métodos de extensión de ese espacio de nombre entren en danza. Lo malo: un espacio de nombre es una entidad sin "chicha" en .NET. Pueden definirse tipos para un espacio de nombre en más de un ensamblado. De modo que al incluir el using, estamos activando todas extensiones, sin importar en qué ensamblado vengan. Además, la cláusula using ya tiene su propia función. Pueden surgir casos en los que nos interese el uso normal y no el extendido. Por supuesto, con mucho cuidado, no tendrían que surgir problemas... pero no deja de ser chapucero.

Exportación selectiva

Mientras releo el código fuente del sistema de ventanas que mencionaba hace unos días, me reafirmo en mi idea sobre cuál es la primera característica que le añadiría a los lenguajes .NET: la exportación selectiva de sus miembros.

Esta idea, como tantas otras, la conozco a través de Eiffel. En las clases de este lenguaje no existen las típicas secciones private, public o protected, popularizadas por C++. Los miembros de una clase se agrupan en secciones encabezadas por la palabra clave feature (debería tener una "s" final para estar en tercera persona del singular; lo mismo ocurre con require o ensure). Estas cabeceras de sección pueden incluir una lista de clases que pueden utilizar los miembros agrupados bajo ella:

class FULANA
feature

feature { MENGANA, ZUTANA }

feature { NONE }

end

La idea que me ronda no es eliminar el actual sistema de niveles de acceso. En principio, sólo sería necesario ampliar las posibilidades del nivel internal. Ahora mismo, cualquier miembro declarado internal está al alcance de cualquier otra clase definida en el mismo ensamblado. Barra libre, por así decirlo. Imposible saber quién está toqueteando indebidamente el método X y por qué razón lo hace. Menos mal que existe un comando Buscar todas las referencias... pero no es lo mismo.

Lo peor de todo es que existen poderosos motivos para que un programador decida declarar métodos y propiedades internas... cargándose la mantenibilidad del sistema que está programando. Usted ha comenzado a programar su sistema como una aplicación monolítica. Luego se ha dado cuenta de que puede manejar la aplicación desde otra aplicación independiente: basta con utilizar el ejecutable como si fuese una biblioteca de clases. El compilador de línea de comandos de Freya, por ejemplo, es un fichero ejecutable que implementa una aplicación de consola, pero el entorno de desarrollo carga el ejecutable como si se tratase de un ensamblado en formato DLL. El problema es que, casi siempre, las clases dentro del ejecutable habrán sido originalmente diseñadas como clases públicas. Bien, usted esconde las clases A y B pero, ¡qué mala pata!, la clase C tiene una propiedad pública que devuelve un objeto de tipo A. No podemos redeclarar esa propiedad como privada, porque medio programa la utiliza... pero tampoco nos interesa que esté al alcance de cualquier mindundi. ¿La solución? El programador redeclara la propiedad como internal... sin darse cuenta de que acaba de hundirse hasta la cintura en el fango.

Mi propuesta consiste en mantener la misma sintaxis y semántica que ahora tienen los restantes niveles de visibilidad en .NET, y además permitir que el modificador internal pueda ir acompañado por una lista de clases. Tenga presente que el efecto de internal se limita al ensamblado donde se declara. Por lo tanto, este tipo de propuesta es ideal: se logra un efecto muy beneficioso sin necesidad de afectar el funcionamiento de los lenguajes de la plataforma que decidan no secundar la idea.

Aviso: si has comprado un pack ISSE/Intuitive Delphi

Si has comprado un pack IntSight's Server Explorer/Intuitive Delphi el tres de este mes, por favor, ponte en contacto conmigo por email. El mensaje de confirmación de la compra, con los datos para la zona de descargas, me está rebotando constantemente con "problemas permanentes en la cuenta".

El CD está, de todos modos, en camino, pero estando la Semana Santa por medio, puede aún tardar en llegar (este producto se envía por correo, no por mensajería).

Tres punto cinco...

... y una pequeña corrección a los comentarios: será .NET 3.5.

Ese es el número de versión que aparece en la beta de Orcas (vaya nombrecito): el Visual Studio 2007, por llamarlo de algún modo. Lo cierto es que toda esta complicación es culpa de la propia Microsoft, que ha tenido que hacer filigranas con las fechas de salida del Windows Vista y el número de versión de .NET para esa familia de productos.

De todos modos, que no cunda el pánico: .NET 3.0 tiene novedades interesantes, pero ninguna que afecte "profundamente" al desarrollo de bases de datos. Al menos, ninguna que empuje a los renuentes a saltar al carro. Mi consejo es el obvio: hay que ser prudentes con la adopción de WFC. No porque tenga algún problema, sino por tratarse de una novedad ligada a una versión específica del sistema operativo (no es exactamente así, pero para abreviar...).

También sería buena la prudencia respecto a LINQ, el nuevo ADO.NET Entity Framework y esas cosas, aunque por motivos diferentes. La adopción de estas nuevas técnicas no está limitada por la base de instalaciones de un sistema operativo: afectan solamente al programador, y si funcionan bien, nada impide que salte al vagón. Mi impresión, de momento, es positiva... pero repito, hay que ser prudentes. Puede que esta vez estemos frente a la técnica que domestique, de una vez por todas, los famosos "persistency frameworks", pero me asusta ver a gente que tenía por sensata (no, no estoy regañando a ninguno de nosotros) quemar tanto incienso por las extensiones al lenguaje inspiradas por la programación funcional.

El problema consiste en que, para que toda esta historia funcione, no basta con que Anders Hejlsberg sea un monstruo de los lenguajes: hace falta que el equipo completo que tiene que escribir las clases de soporte para tiempo de ejecución haga bien las cosas. Y aunque, repito, creo que todo va a salir bien y que va a ser un producto estupendo, no puedo olvidar que la idea de los "Object Spaces" ha estado dando tumbos desorientada por todo el campus de Microsoft hasta que Hejlsberg y compañía se han atrevido a agarrar el toro por los cuernos.

Ideas para superar el famoso "impedance mismatch" existen desde que se inventó la palabreja de marras. Suelen parecer ideas sencillas y, por lo mismo, geniales... pero hasta ahora, el monstruo que pretenden matar goza de buena salud. Es muy probable, diría que casi seguro, que esta vez sea la definitiva. Pero le aconsejo que no contenga la respiración hasta entonces...