Concido en que debería ser una característica opcional o mejor aún que no modifique el código automáticamente sino que se produzca una advertencia no intrusiva para que el programador sea quien decida qué hacer.
La cuestión respecto de la modificación automática del código es que puede conducir a errores lógicos. Por ejemplo, si declaro una variable con un nombre cualquiera y luego al usarla cometo un error de escritura cambiando un caracter en ese nombre, el IDE crearía una variable nueva cuando lo que ocurre, en realidad, es que quise usar la misma variable pero he escrito mal su nombre. Esto en ciertas situaciones puede convertirse en un error cuya detección y corrección, aunque es simple, demande una importante cantidad de tiempo.
gambas es muy particular en cuanto al manejo de tipos de datos: es de tipos fuerte, es decir que en principio una variable declarada de un tipo no puede alojar un valor de otro tipo, pero como la mayoría de los lenguajes de tipos fuertes,
gambas utiliza conversiones para relajar estas restricciones; éstas pueden ser explícitas o implícitas y sus particularidades son que dispone de una importante cantidad de conversiones implícitas y que a pesar de exigir la declaración de tipos la verificación la realiza en tiempo de ejecución (esto último ¿tiene sentido?).
La misma existencia de conversiones de tipos implica un contrasentido, para qué en primer lugar existen esas restricciones si luego un lenguaje incorpora gran cantidad de conversiones explícitas o implícitas para saltearlas. Puede pensarse que en ciertas situaciones es útil que esas restricciones existan y en otras es útil poder evitarlas.
En realidad, las restricciones impuestas por un sistema de tipos vienen a ser una forma automática de verificación respecto de que a un tipo de datos sólo se le apliquen operaciones válidas. Desde un punto de vista más centrado en la programación orientada a objetos, un tipo es una clase y las operaciones que pueden ser aplicadas a esa clase son los mensajes a los que sabe responder (sus métodos).
De modo que en un lenguaje verdaderamente orientado a objetos la declaración del tipo de datos también puede ser implícita, porque lo que restringe las operaciones válidas sobre un tipo no tiene por qué ser su declaración, sino su protocolo de mensajes (la lista de sus métodos).
Entonces, no hay necesidad real de declarar el "tipo" de una variable ya que la determinación de su tipo se puede diferir al tiempo de ejecución, lo que comunmente se llama sistema de tipos dinámicos.
Declarar el tipo de las variables es una forma de documentar la funcionalidad buscada para un segmento de código e implica que el programador toma como una línea fundamental de razonamiento (aunque no la única) al sistema de tipos en sí mismo.
Sin embargo, ésto no sólo no es estrictamente necesario sino que muchas veces es contraproducente. Por qué un programador debería verse obligado a pensar en las reglas y restricciones de compilación del lenguaje, en vez de pensar en términos del dominio del problema (que es precisamente una de las principales ventajas de la programación orientada a objetos).
El problema se reduce a casi nada si el lenguaje tiene un diseño consistente porque dichas reglas de compilación se resumirán básicamente a que no puedes enviar al objeto A el mensaje X porque ni la clase del objeto A ni ninguna de sus superclases lo implementa. Sin embargo, si incluye "tipos de datos" que no son objetos y otras construcciones, símbolos, operadores que tampoco son objetos o mensajes, sino elementos particulares del lenguaje, el problema se hace evidente.
La mayor ventaja de un sistema de tipos fuerte (que obliga a la declaración explícita del tipo de datos de las variables) es que la verificación de tipos se haga en tiempo de compilación. Siguiendo la línea de razonamiento que impone el sistema de tipos un programa que no compila no es válido porque el programador intentó aplicar a un tipo de datos una operación no válida. Además, que la verificación de tipos sea estática, es decir, en tiempo de compilación, implica que la realimentación es inmediata.
Pero lenguajes como
gambas obligan a declarar los tipos y realizan la verificación de tipos en tiempo de ejecución logrando, en mi humilde opinión, reunir lo peor de ambos mundos: obliga a declarar el tipo de las variables y no brinda realimentación inmediata porque es necesario ejecutar el programa y que el flujo de ejecución pase exactamente por la rutina y la línea de código que aplica la operación inválida para que el programador sea avisado mediante un mensaje de error.
Por supuesto, es algo con lo que todo programador
gambas ha convivido y sabemos que no es un problema de vida o muerte. Sin embargo, lo importante es lo que subyace a todo esto y es precisamente qué líneas de razonamiento induce el lenguaje en el programador.
Si pensamos en que a un objeto sólo se le pueden enviar los mensajes que conoce (los métodos declarados en su clase o sus superclases), todo lo que el programador necesita del IDE es una ayuda memoria respecto de cuáles son los mensajes válidos (cuáles son las operaciones válidas sobre ese "tipo de datos").
Por supuesto, aún contando con esa ayuda esencial parece bastante obvio que cualquier ser humano puede cometer errores, más aún si el programa en desarrollo es extenso, si el programador puede estar trabajando bajo cierta presión (fechas de entrega), si carga con cierto cansancio normal o por distracciones que ningún ser humano puede evitar (normalmente la atención disminuye bruscamente por al menos unos 5 minutos después de 45 minutos de concentración intensa).
Debido a ello, sí que es útil que exista algún sistema de alertas que le avise al programador que cometió un error, por más que se trate de un error trivial. Pero ese sistema de avisos bien puede ser uno implementado por el IDE mediante alertas no intrusivas que incluyan una explicación del error y sugerencias de solución (al estilo eclipse).
Para ayudar al programador a darse cuenta que ha cometido un error de escritura, bastaría con el sistema de corrección automática típico de los procesadores de texto (la viborita roja debajo de la palabra mal escrita). Así, si utilizo una variable no declarada, lo primero que haría el IDE sería señalarme ese hecho: si se trata de un error de escritura podría permitirme la corrección mediante la pulsación de una combinación de teclas (implica que el IDE debe detectar qué variable ya declarada se asemeja más a lo que he escrito), en caso contrario mediante otra combinación de teclas podría permitirme incluir la declaración de la nueva variable.
Por supuesto esto es materia opinable y ni siquiera expresa una opinión formada de mi parte, sino más bien son sólo pensamientos en voz alta.
Saludos.