Internal affaires

¿Y si llevásemos la propuesta de exportación selectiva aún más lejos? Quiero decir, ¿y si permitiésemos la mención de rutinas, propiedades y eventos en la lista de entidades con acceso a un recurso? Actualmente, en la sintaxis de Freya, la exportación selectiva tiene este aspecto:

MiClase = class
internal(OtraClase, YOtraMas)
    Campo: Integer;
    // ... etcétera ...
end;

Lo que ahora digo es esto otro:

MiClase = class
internal(MiClase.Propiedad)
    Campo: Integer;
    // ... etcétera ...
end;

Sí, este es un ejemplo "extremo": sólo permito que Campo sea usado por el código de la propiedad Propiedad... de la misma clase donde se ha definido Campo. En circunstancias normales, no habría que caer en el "tremendismo", pero esto permite usar una técnica que he echado de menos en ocasiones. Por ejemplo, en el editor de código se define un campo privado para almacenar la posición del curso. En paralelo, se usa una propiedad para encapsular esta posición. El caso es que, cuando se cambia la línea activa, se producen cambios en el búfer de líneas interno. Sin embargo, es relativamente seguro modificar directamente la columna activa... y uno, que es un triste pecador, lo ha hecho en varias ocasiones. De haber tenido la disciplina suficiente, podría haber asociado un evento a las escrituras en la propiedad. Pero, ¿quién localiza, a estas alturas, todas las violaciones de esta "regla"? Con la posibilidad de reducir el uso de un campo a una propiedad, como propongo, sería muy sencillo, no ya cumplir con la regla, sino ponerla inmediatamente en conocimiento de quien lee el código.

Resumamos las bondades de mi propuesta:

• Se reduce fulminantemente la cantidad absoluta de dependencias potenciales entre clases, e incluso dentro de la misma clase.
• Como esta técnica afecta solamente a las declaraciones internas, no hay peligro alguno de interacción con otros lenguajes .NET. Puedo seguir utilizando desde C# un ensamblado escrito en Freya, y viceversa.
• Cuando en la lista de "entidades" a las que se le permite el acceso aparece una clase, se entiende que es lo mismo que "Clase.*": se le concede acceso a todos los miembros de la clase mencionada.
• Este tipo de restricciones de acceso pueden interpretarse también como una modalidad de contrato ligado a la implementación de un recurso. Este tipo de contrato ya es muy popular entre los programadores, pero no existe una forma sencilla de hacerlo explícito.

La visión reduccionista

Una reflexión al margen: otra solución al evento que falta en mi editor de código podría utilizar la Programación Orientada a Aspectos: podría indicar que, para todos los métodos que modifiquen la posición del cursor, se genere un prólogo en el que se memorice la posición inicial, y un epílogo que dispare el evento si se han producido cambios. Menciono esto porque es importante observar la gran diferencia entre la solución OOP y la solución AOP. Y la observación tiene que ver con el énfasis que pone la AOP en el texto del programa. La visión OOP monta capas y más capas de abstracciones sobre las tiras de caracteres del programa, mientras que la visión AOP, al centrarse en el texto, se podría calificar incluso de reduccionista.

Y no se trata de un mero florilegio retórico. Por una parte, está demostrado que la AOP resuelve algunos problemas (no todos) de manera más eficiente, sencilla y controlable que la OOP. Pero se trata de sustituir una cosa por la otra... porque no es ese el propósito de la AOP. Se trata de que este enfoque reduccionista puede aportar claridad a muchos debates viciados. Durante tiempo hemos intentado juzgar la OOP según sus propios reglas. ¿El resultado? Pues que cada vez es más difícil evaluar los méritos de las propuestas y novedades. Y por otra parte, vemos a autores a los que se le supone cierta seriedad defendiendo tonterías como el llamado "duck typing".

¿Una pista sobre el impacto que puede tener la visión "reduccionista" en Informática? Ahí tiene el revuelo que han traido consigo las clases parciales de .NET 2.0. En principio, se trataría de un mero "truco" de ficheros... pero resulta que el "truco" ha encontrado aplicaciones de todo tipo. Y es que, al fin y al cabo, una de las grandes justificaciones de la OOP tiene que ver con la "mera" distribución del código fuente: en la programación estructurada original, se tendería a organizar el código de acuerdo a su función, mientras que en la OOP, el código se agruparía respecto al "propietario" de cada método. Eso facilitaría la adición de nueva funcionalidad: observe que se trata de una justificación textual y reduccionista.

Bienvenido sea el reduccionismo...