Eso le pregunté a Anders Hejlsberg, el arquitecto principal de .NET y "alma mater" del lenguaje C#, la primera vez que lo entreviste, hace ya 10 años. La respuesta me dejo helado, por que no me esperaba algo así, y dió lugar a muchos paréntesis en mis clases donde explicaba esto con más detalle. Hoy lo quiero compartir aquí, ya que se sale de la mera teoría. Su respuesta: "No me quedó más remedio..." (¿?)
Ante mi sorpresa, Hejlsberg profundizó en el tema comentándome que, cuando Gates le hizo la correspondiente oferta (IRresistible, por que implementaba la interfaz "no puedo decir que no"), una de las cosas que antepuso fue terminar con las infames BSOD's.(pantallas azules, ya sabéis). Así que, como es un científico, abordó el problema de forma científica, y comenzo por hacer una análisis estadístico de cuáles eran sus causas. Resultó que el 90% eran debidas a drivers, y ahí solo podían ponerse serios con los fabricantes y poco más. PERO, el 10% restante, que era por causa propia, obedecía ¡en su 99%! a solo dos razones: Punteros a función perdidos y problemas "Casting" (conversión de tipos). La gaussinana resultante tenía un aspecto similar a este: (Y me hizo un dibujo parecido al que adjunto aquí):
1º Objetivo cumplido: focalizar el problema y reducirlo al máximo.
Ahora venía el segundo: dar con una solución -única a ser posible- que resolviese ambos. Y aquí es donde entra la auténtica genialidad de este danés. Vuelve a pensar en los orígenes de los dos problemas y se da cuenta de que en los dos casos se relacionan con la llamadas a métodos. Le da una vuelta de tuerca más y vuelve a replantearse las bases de la Teroría General de la Información, para identificar al problema concreto dentro del modelo teórico: (primera página de cualquier libro sobre el tema): Emisor - Receptor - Canal e Información transmitida. Pero...¡eso es el sistema de eventos! Emisor -> La clase que llama usando un método. Receptor -> Otra (o la misma clase) que recibe (en otro método). CANAL (el vacío del entorno de ejecución - que el sustituirá por un entorno ADMINISTRADO) e Información transmitida (los valores que pasamos al receptor).
2º Problema resuelto: el modelo sobre el que se actuará queda indentificado de inicio como parte del modelo general de la TGI. Y sus partes, también: el CANAL y la recepción de los tipos esperados.
¿Qué faltaba? Lo que siempre se ha hecho en Informática para resolver problemas propios de las llamadas directas: poner un intermediario. UN DELEGADO. Las llamadas ya no se harán nunca de forma directa, sino a través del delegado, que -al estar administrado por el CLR- no intentará llamar a algo que no está disponible. Problema del puntero a función resuelto por la vía del canal (y por la eliminación de los punteros, claro).
La solución a la segunda causa, decía Hejlsberg, "me pareció trivial, una vez resulto lo anterior". Basta con que el delegado que hace las llamadas TENGA LA MISMA SIGNATURA (recordemos, mismos tipos de parámetros y mismo valor de retorno), que el receptor, y, ¡adiós a los problemas de "casting"!, y, por ende, adiós a los problemas de las BSOD por esas causas.
Hejlsberg se fue a Canada durante 6 meses a pensar sobre el asunto, pero una vez planteado al problema, afirmaba que lo resolvió en un fin de semana (al menos en teoría). Su gran apoyo: el trabajo serio, con método y los conocimientos profundos de los fundamentos. Hasta hoy no he visto nada que contradiga esos principios.
Saludos y buen verano.
PD: Se admiten comentarios, apostillas y todo tipo de opiniones. El tema creo que lo merece.
Marino