Cosas mías

… y que rompe por completo las reglas de todo lenguaje de programación, de toda lógica y lo que es peor, del mismo concepto de orientación a objetos. Por lo menos así lo creo, y me gustaría estar equivocado (y que alguien me lo demostrara).

El primer tema es el hecho de que los tipos básicos, las enumeraciones, las estructuras y los delegados hereden automática y ocultamente de clases .NET. Y la palabra clave es "ocultamente". ¿Por qué? Entiendo el tema del "encajado" y "desencajado", pero no puedo entender esa ocultación. Como en la teoría cuántica, hay elementos que son objetos y que no lo son, y de la misma forma que en la teoría cuántica la medición de un objeto lo colapsa, así ocurre con el C#: cuando miramos un elemento de los citados, o es un objeto o un elemento básico, con la sobrecarga que eso conlleva: si antes era lo contrario, hay que convertirlo al nuevo valor, con pérdida de tiempo y de recursos.

Pero también ocurren otras cosas un tanto extrañas. Veámoslo con un ejemplo. Una enumeración hereda de System.Enum, pero sin embargo dicho System.Enum no es una enumeración, sino una clase. Y justo al revés, una enumeración es una enumeración (en el concepto tradicional) que podemos convertir en objeto y que así pase a ser algo alojado en el montículo y que tiene los miembros de System.Enum. Y yo me digo, ¿qué más da que esté en la pila o en el montículo? Es un objeto y ya está. O no lo es. ¿Por qué cuando está en la pila no podemos usar sus métodos miembros y sí cuando está en el montículo? Y lo más incomprensible para mí: cada vez que usamos una enumeración como tal, la tenemos en la pila, y cuando la usamos como un objeto, debemos pasarla al montículo, y de nuevo al revés. Me vais a perdonar pero no lo entiendo.

Lo que veo (y me gustaría no ver) es lo que considero una serie de errores de concepto garrafales en todo el .NET; la propia idiosincrasia del .NET está mal, al menos en los aspectos que cito. ¿Por qué toda esa manía de que todo sea un objeto cuando evidentemente muchas cosas no lo son? Repito que es una apreciación personal, pero de momento es la que tengo. Y se va confirmando conforme voy leyendo el libro de Hejlsberg.

Otro tema que me trae de cabeza son los destructores. ¿Los hay? Según Hejlsberg sí, pero resulta que se implementan mediante la sobreescritura del método Finalize de la clase System.Object. Pero entonces no son destructores, sino algo que el sistema en tiempo de ejecución llama cuando el recolector de basura así lo decide. Al final, en las pocas páginas en las que se trata el tema (352-354) no queda nada claro, pero nada de nada la finalidad y el objeto de los destructores, así como el uso de Finalize. Y tampoco menciona qué pasa con Dispose. La verdad es que parece que ni el propio creador del lenguaje se entera. ¿Cómo vamos, pues, a enterarnos los mortales comunes?

Todavía queda una cosa más: la palabra reservada extern en constructores, destructores y demás elementos de una clase. Parece ser que son elementos que no tienen implementación. Pero no se dan más explicaciones. Ni dónde se podría encontrar, ni cómo, ni para qué sirven. En otros lenguajes con extern indicamos que dicho elemento está implementado en otro lugar, pero que dicha implementación existe en algún lugar. Hejlsberg no nos dice nada sobre ello. Pero aquí hay truco, aunque venga después. No sé si el libro lo documenta, pero espero que sí. Dejamos al lector que se imagine para qué puede servir dicho extern, pero diremos que desde mi punto de vista es otra de esas "cosas raras" que no me gustan un pelo del C# y por extensión del .NET

Me vais a perdonar la expresión, pero considero que por estos aspectos (y alguno más que ya he mencionado con anterioridad) el .NET y el C# (y por supuesto el VB.NET y el C++/CLI que es CLI) es un aborto, carente de mucha lógica y consistencia.