Introducción a Visual Basic

El lenguaje de programación de Microsoft® Visual Basic® es un lenguaje de programación de alto nivel para Microsoft .NET Framework. Aunque está diseñado para ser un lenguaje accesible y fácil de aprender, también es lo suficientemente eficaz como para satisfacer las necesidades de los programadores experimentados. El lenguaje de programación de Visual Basic tiene una sintaxis similar al inglés, que promueve la claridad y legibilidad del código de Visual Basic. Siempre que sea posible, se usan palabras o frases significativas en lugar de abreviaturas, acrónimos o caracteres especiales. Por lo general, se permite una sintaxis extraña o innecesaria, pero no es necesaria.

El lenguaje de programación de Visual Basic puede ser un lenguaje fuertemente tipado o un lenguaje de tipo flexible. La escritura suelta aplaza gran parte de la carga de la comprobación de tipos hasta que ya se esté ejecutando un programa. Esto incluye no solo la comprobación de tipos de conversiones, sino también de llamadas de método, lo que significa que el enlace de una llamada de método se puede aplazar hasta el tiempo de ejecución. Esto resulta útil cuando se crean prototipos u otros programas en los que la velocidad de desarrollo es más importante que la velocidad de ejecución. El lenguaje de programación de Visual Basic también proporciona semántica fuertemente tipada que realiza todas las comprobaciones de tipos en tiempo de compilación y no permite el enlace en tiempo de ejecución de las llamadas de método. Esto garantiza el máximo rendimiento y ayuda a garantizar que las conversiones de tipos son correctas. Esto resulta útil cuando se crean aplicaciones de producción en las que es importante la velocidad de ejecución y corrección de la ejecución.

En este documento se describe el lenguaje de Visual Basic. Está pensado para ser una descripción completa del idioma en lugar de un tutorial de lenguaje o un manual de referencia de un usuario.

Notación gramatical

Esta especificación describe dos gramáticas: una gramática léxica y una gramática sintáctica. La gramática léxica define cómo se pueden combinar caracteres para formar tokens; La gramática sintáctica define cómo se pueden combinar los tokens para formar programas de Visual Basic. También hay varias gramáticas secundarias que se usan para las operaciones de preprocesamiento, como la compilación condicional.

Las gramáticas de esta especificación se escriben en formato ANTLR; vea http://www.antlr.org/.

El caso no es importante en los programas de Visual Basic. Por motivos de simplicidad, todos los terminales se proporcionarán en mayúsculas y minúsculas estándar, pero las mayúsculas y minúsculas coincidirán con ellas. Los terminales que son elementos imprimibles del juego de caracteres ASCII se representan mediante sus caracteres ASCII correspondientes. Visual Basic también no distingue el ancho cuando coinciden los terminales, lo que permite que los caracteres Unicode de ancho completo coincidan con sus equivalentes Unicode de ancho medio, pero solo en un token completo. Un token no coincidirá si contiene caracteres mixtos de ancho medio y ancho completo.

Los saltos de línea y la sangría se pueden agregar para mejorar la legibilidad y no forman parte de la producción.

Compatibilidad

Una característica importante de un lenguaje de programación es la compatibilidad entre diferentes versiones del lenguaje. Si una versión más reciente de un lenguaje no acepta el mismo código que una versión anterior del idioma, o lo interpreta de forma diferente a la versión anterior, se puede colocar una carga en un programador al actualizar su código de una versión del lenguaje a otra. Por lo tanto, la compatibilidad entre versiones debe conservarse, excepto cuando la ventaja para los consumidores del lenguaje es de una naturaleza clara y abrumadora.

La siguiente directiva rige los cambios en el lenguaje de Visual Basic entre versiones. El término lenguaje, cuando se usa en este contexto, hace referencia solo a los aspectos sintácticos y semánticos del propio lenguaje de Visual Basic y no incluye ninguna clase de .NET Framework incluida como parte del Microsoft.VisualBasic espacio de nombres (y los subespacios de nombres). Todas las clases de .NET Framework están cubiertas por una directiva independiente de control de versiones y compatibilidad fuera del ámbito de este documento.

Tipos de interrupciones de compatibilidad

En un mundo ideal, la compatibilidad sería 100% entre la versión existente de Visual Basic y todas las versiones futuras de Visual Basic. Sin embargo, puede haber situaciones en las que la necesidad de una interrupción de compatibilidad puede superar el costo que puede imponer a los programadores. Estas situaciones son:

• Nuevas advertencias. La introducción de una nueva advertencia no es, por se, una interrupción de compatibilidad. Sin embargo, dado que muchos desarrolladores compilan con "tratar advertencias como errores" activadas, se debe tener cuidado adicional al introducir advertencias.

• Palabras clave nuevas. Es posible que sea necesario introducir nuevas palabras clave al introducir nuevas características de lenguaje. Se realizarán esfuerzos razonables para elegir palabras clave que minimicen la posibilidad de colisión con los identificadores de los usuarios y para usar las palabras clave existentes donde tenga sentido. Se proporcionará ayuda para actualizar proyectos de versiones anteriores y escapar de las nuevas palabras clave.

• Errores del compilador. Cuando el comportamiento del compilador está en desacuerdo con un comportamiento documentado en la especificación del lenguaje, es posible que sea necesario corregir el comportamiento del compilador para que coincida con el comportamiento documentado.

• Error de especificación. Cuando el compilador es coherente con la especificación del lenguaje, pero la especificación del lenguaje es claramente incorrecta, puede ser necesario cambiar la especificación del lenguaje y el comportamiento del compilador. La frase "claramente incorrecta" significa que el comportamiento documentado se ejecuta en contra de lo que una mayoría clara e inequívoca de los usuarios esperaría y genera un comportamiento muy no deseado para los usuarios.

• Ambigüedad de especificación. Cuando la especificación del lenguaje debe explicar lo que sucede en una situación determinada, pero no, y el compilador controla la situación de una manera que sea incoherente o claramente incorrecta (con la misma definición desde el punto anterior), es posible que sea necesario aclarar la especificación y corregir el comportamiento del compilador. En otras palabras, cuando la especificación abarca casos a, b, d y e, pero omite cualquier mención de lo que sucede en el caso c, y el compilador se comporta incorrectamente en caso de c, puede ser necesario documentar lo que sucede en caso c y cambiar el comportamiento del compilador para que coincida. (Tenga en cuenta que si la especificación era ambigua en cuanto a lo que sucede en una situación y el compilador se comporta de una manera que no es claramente incorrecta, el comportamiento del compilador se convierte en la especificación de facto).

• Realizar errores en tiempo de ejecución en errores en tiempo de compilación. En una situación en la que el código es 100% se garantiza que se produzca un error en tiempo de ejecución (es decir, el código de usuario tiene un error inequívoco en él), puede ser conveniente agregar un error en tiempo de compilación que detecte la situación.

• Omisión de especificación. Cuando la especificación del lenguaje no permite o no permite específicamente una situación determinada y el compilador controla la situación de una manera no deseada (si el comportamiento del compilador era claramente incorrecto, sería un error de especificación, no una omisión de especificación), puede ser necesario aclarar la especificación y cambiar el comportamiento del compilador. Además del análisis de impacto habitual, los cambios de este tipo se restringen aún más a los casos en los que el impacto del cambio se considera extremadamente mínimo y la ventaja para los desarrolladores es muy alta.

• Nuevas características. En general, la introducción de nuevas características no debe cambiar las partes existentes de la especificación del lenguaje ni el comportamiento existente del compilador. En la situación en la que la introducción de una nueva característica requiere cambiar la especificación del lenguaje existente, este salto de compatibilidad es razonable solo si el impacto sería extremadamente mínimo y la ventaja de la característica es alta.

• Seguridad. En situaciones extraordinarias, los problemas de seguridad pueden requerir una interrupción de compatibilidad, como quitar o modificar una característica que es intrínsecamente insegura y supone un riesgo de seguridad claro para los usuarios.

Las situaciones siguientes no son razones aceptables para introducir interrupciones de compatibilidad:

• Comportamiento no deseado o lamentable. El diseño del lenguaje o el comportamiento del compilador, que es razonable, pero que se considera no deseado o lamentable en retrospectiva no es una justificación para interrumpir la compatibilidad con versiones anteriores. El proceso de desuso del idioma, que se describe a continuación, debe usarse en su lugar.

• Algo más. De lo contrario, el comportamiento del compilador sigue siendo compatible con versiones anteriores.

Criterios de impacto

Al considerar si una interrupción de compatibilidad puede ser aceptable, se usan varios criterios para determinar cuál podría ser el impacto del cambio. Cuanto mayor sea el impacto, mayor será la barra para aceptar los saltos de compatibilidad.

Los criterios son:

• ¿Cuál es el ámbito del cambio? En otras palabras, ¿cuántos programas probablemente se vean afectados? ¿Cuántos usuarios probablemente se verán afectados? ¿Qué tan común será escribir código afectado por el cambio?

• ¿Existen soluciones alternativas para obtener el mismo comportamiento antes del cambio?

• ¿Qué tan obvio es el cambio? ¿Los usuarios recibirán comentarios inmediatos que algo ha cambiado o que sus programas se ejecutarán de forma diferente?

• ¿Se puede solucionar el cambio razonablemente durante la actualización? ¿Es posible escribir una herramienta que pueda encontrar la situación en la que se produce el cambio con precisión perfecta y cambiar el código para solucionar el cambio?

• ¿Cuáles son los comentarios de la comunidad sobre el cambio?

Desuso del idioma

Con el tiempo, las partes del lenguaje o el compilador pueden quedar en desuso. Como se explicó anteriormente, no es aceptable interrumpir la compatibilidad para quitar estas características en desuso. En su lugar, se deben seguir los pasos siguientes:

1. Dada una característica que existe en la versión A de Visual Studio, los comentarios deben solicitarse de la comunidad de usuarios sobre el desuso de la característica y la notificación completa dada antes de tomar cualquier decisión final de desuso. El proceso de desuso puede revertirse o abandonarse en cualquier momento en función de los comentarios de la comunidad de usuarios.

2. versión completa (es decir, no una versión puntual) B de Visual Studio debe publicarse con advertencias del compilador que advierten del uso en desuso. Las advertencias deben estar activadas de forma predeterminada y se pueden desactivar. Las desusos deben estar claramente documentadas en la documentación del producto y en la web.

3. Se debe publicar una versión completa de Visual Studio con advertencias del compilador que no se pueden desactivar.

4. Una versión completa D de Visual Studio debe publicarse posteriormente con las advertencias del compilador en desuso convertidas en errores del compilador. La versión de D debe producirse después del final de la fase de soporte estándar (5 años a partir de este escrito) de la versión A.

5. Por último, se puede liberar una versión E de Visual Studio que quite los errores del compilador.

No se permitirán los cambios que no se pueden controlar en este marco de desuso.