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.