Introdução ao Visual Basic

A linguagem de programação Microsoft® Visual Basic® é uma linguagem de programação de alto nível para o Microsoft .NET Framework. Embora seja projetado para ser uma linguagem acessível e fácil de aprender, também é poderoso o suficiente para satisfazer as necessidades de programadores experientes. A linguagem de programação Visual Basic tem uma sintaxe que é semelhante ao inglês, que promove a clareza e legibilidade do código Visual Basic. Sempre que possível, são utilizadas palavras ou frases significativas em vez de abreviaturas, acrónimos ou carateres especiais. Sintaxe estranha ou desnecessária é geralmente permitida, mas não necessária.

A linguagem de programação Visual Basic pode ser uma linguagem fortemente tipada ou vagamente tipada. A digitação solta adia grande parte da carga de verificação de tipo até que um programa já esteja em execução. Isso inclui não apenas a verificação de tipo de conversões, mas também de chamadas de método, o que significa que a vinculação de uma chamada de método pode ser adiada até o tempo de execução. Isso é útil ao construir protótipos ou outros programas em que a velocidade de desenvolvimento é mais importante do que a velocidade de execução. A linguagem de programação Visual Basic também fornece semântica fortemente tipada que executa toda a verificação de tipo em tempo de compilação e não permite a vinculação em tempo de execução de chamadas de método. Isso garante o máximo desempenho e ajuda a garantir que as conversões de tipo estejam corretas. Isso é útil ao construir aplicações de produção nas quais a velocidade de execução e a correção da execução são importantes.

Este documento descreve a linguagem Visual Basic. Destina-se a ser uma descrição completa da língua, em vez de um tutorial de linguagem ou um manual de referência do usuário.

Notação gramatical

Esta especificação descreve duas gramáticas: uma gramática lexical e uma gramática sintática. A gramática lexical define como os caracteres podem ser combinados para formar tokens; a gramática sintática define como os tokens podem ser combinados para formar programas Visual Basic. Há também várias gramáticas secundárias usadas para operações de pré-processamento, como compilação condicional.

As gramáticas nesta especificação são escritas no formato ANTLR - veja http://www.antlr.org/.

Caso não é importante em programas Visual Basic. Para simplificar, todos os terminais serão fornecidos em caixa padrão, mas qualquer invólucro corresponderá a eles. Os terminais que são elementos imprimíveis do conjunto de caracteres ASCII são representados por seus caracteres ASCII correspondentes. O Visual Basic também é insensível à largura ao combinar terminais, permitindo que caracteres Unicode de largura total correspondam aos seus equivalentes Unicode de meia largura, mas apenas em uma base de token inteiro. Um token não corresponderá se contiver caracteres mistos de meia largura e largura total.

Quebras de linha e recuo podem ser adicionados para facilitar a leitura e não fazem parte da produção.

Compatibilidade

Uma característica importante de uma linguagem de programação é a compatibilidade entre diferentes versões da linguagem. Se uma versão mais recente de uma linguagem não aceitar o mesmo código que uma versão anterior da linguagem, ou interpretá-lo de forma diferente da versão anterior, então um fardo pode ser colocado sobre um programador ao atualizar seu código de uma versão da linguagem para outra. Como tal, a compatibilidade entre versões deve ser preservada, exceto quando o benefício para os consumidores linguísticos é de natureza clara e esmagadora.

A política a seguir rege as alterações na linguagem Visual Basic entre versões. O termo linguagem, quando usado neste contexto, refere-se apenas aos aspetos sintáticos e semânticos da própria linguagem Visual Basic e não inclui quaisquer classes do .NET Framework incluídas como parte do Microsoft.VisualBasic namespace (e sub-namespaces). Todas as classes no .NET Framework são cobertas por uma política de controle de versão e compatibilidade separada fora do escopo deste documento.

Tipos de quebras de compatibilidade

Em um mundo ideal, a compatibilidade seria de 100% entre a versão existente do Visual Basic e todas as versões futuras do Visual Basic. No entanto, pode haver situações em que a necessidade de uma quebra de compatibilidade pode superar o custo que pode impor aos programadores. Tais situações são:

• Novos avisos. A introdução de um novo aviso não é, por si só, uma quebra de compatibilidade. No entanto, como muitos desenvolvedores compilam com a opção "tratar avisos como erros" ativada, é necessário ter cuidado extra ao introduzir avisos.

• Novas palavras-chave. A introdução de novas palavras-chave pode ser necessária ao introduzir novos recursos linguísticos. Serão feitos esforços razoáveis para escolher palavras-chave que minimizem a possibilidade de colisão com os identificadores dos utilizadores e para utilizar palavras-chave existentes onde fizer sentido. Será fornecida ajuda para atualizar projetos de versões anteriores e escapar de novas palavras-chave.

• Bugs do compilador. Quando o comportamento do compilador está em desacordo com um comportamento documentado na especificação da linguagem, a correção do comportamento do compilador para corresponder ao comportamento documentado pode ser necessária.

• Bug de especificação. Quando o compilador é consistente com a especificação da linguagem, mas a especificação da linguagem está claramente errada, alterar a especificação da linguagem e o comportamento do compilador pode ser necessário. A frase "claramente errado" significa que o comportamento documentado vai contra o que uma maioria clara e inequívoca de usuários esperaria e produz um comportamento altamente indesejável para os usuários.

• Ambiguidade da especificação. Quando a especificação de linguagem deve explicar o que acontece em uma situação específica, mas não o faz, e o compilador lida com a situação de uma maneira que é inconsistente ou claramente errada (usando a mesma definição do ponto anterior), esclarecer a especificação e corrigir o comportamento do compilador pode ser necessário. Em outras palavras, quando a especificação abrange os casos a, b, d e e, mas omite qualquer menção ao que acontece no caso c, e o compilador se comporta incorretamente no caso c, pode ser necessário documentar o que acontece no caso c e alterar o comportamento do compilador para corresponder. (Observe que se a especificação era ambígua quanto ao que acontece em uma situação e o compilador se comporta de uma maneira que não está claramente errada, o comportamento do compilador se torna a especificação de fato.)

• Transformar erros em tempo de execução em erros em tempo de compilação. Em uma situação em que o código é 100% garantido para falhar em tempo de execução (ou seja, o código do usuário tem um bug inequívoco nele), pode ser desejável adicionar um erro em tempo de compilação que captura a situação.

• Omissão de especificações. Quando a especificação da linguagem não permite ou não permite especificamente uma situação específica e o compilador lida com a situação de uma forma que é indesejável (se o comportamento do compilador estava claramente errado, seria um bug de especificação, não uma omissão de especificação), pode ser necessário esclarecer a especificação e alterar o comportamento do compilador. Para além da habitual análise de impacto, as alterações deste tipo restringem-se ainda aos casos em que o impacto da alteração é considerado extremamente mínimo e o benefício para os promotores é muito elevado.

• Novos recursos. Em geral, a introdução de novos recursos não deve alterar partes existentes da especificação da linguagem ou o comportamento existente do compilador. Na situação em que a introdução de um novo recurso requer a alteração da especificação de idioma existente, tal quebra de compatibilidade é razoável apenas se o impacto for extremamente mínimo e o benefício do recurso for alto.

• Segurança. Em situações extraordinárias, as preocupações com a segurança podem exigir uma quebra de compatibilidade, como a remoção ou modificação de um recurso que é inerentemente inseguro e representa um claro risco de segurança para os usuários.

As seguintes situações não são razões aceitáveis para a introdução de quebras de compatibilidade:

• Comportamento indesejável ou lamentável. Design de linguagem ou comportamento do compilador que é razoável, mas considerado indesejável ou lamentável em retrospetiva não é uma justificativa para quebrar a compatibilidade com versões anteriores. O processo de depreciação do idioma, abordado abaixo, deve ser usado em vez disso.

• Mais alguma coisa. Caso contrário, o comportamento do compilador permanece compatível com versões anteriores.

Critérios de impacto

Ao considerar se uma quebra de compatibilidade pode ser aceitável, vários critérios são usados para determinar qual pode ser o impacto da alteração. Quanto maior o impacto, maior a barra para aceitar as quebras de compatibilidade.

Os critérios são:

• Qual é o alcance da mudança? Em outras palavras, quantos programas provavelmente serão afetados? Quantos utilizadores são suscetíveis de serem afetados? Quão comum será escrever código que é afetado pela alteração?

• Existem soluções alternativas para obter o mesmo comportamento antes da alteração?

• Quão óbvia é a mudança? Os usuários receberão feedback imediato de que algo mudou ou seus programas serão executados de forma diferente?

• A alteração pode ser razoavelmente resolvida durante a atualização? É possível escrever uma ferramenta que possa encontrar a situação em que a mudança ocorre com perfeita precisão e alterar o código para contornar a mudança?

• Qual é o feedback da comunidade sobre a mudança?

Descontinuação do idioma

Com o tempo, partes da linguagem ou do compilador podem ficar obsoletas. Como discutido anteriormente, não é aceitável quebrar a compatibilidade para remover esses recursos obsoletos. Em vez disso, as seguintes etapas devem ser seguidas:

1. Dado um recurso que existe na versão A do Visual Studio, comentários devem ser solicitados à comunidade de usuários sobre a descontinuação do recurso e aviso completo dado antes de qualquer decisão final de descontinuação ser tomada. O processo de substituição pode ser revertido ou abandonado a qualquer momento com base no feedback da comunidade de usuários.

2. A versão completa (ou seja, não é uma versão pontual) B do Visual Studio deve ser lançada com avisos do compilador que avisam sobre o uso preterido. Os avisos devem estar ativados por padrão e podem ser desativados. As preterições devem ser claramente documentadas na documentação do produto e na Web.

3. Uma versão completa C do Visual Studio deve ser lançada com avisos do compilador que não podem ser desativados.

4. Uma versão completa D do Visual Studio deve ser lançada subsequentemente com os avisos do compilador preteridos convertidos em erros do compilador. A versão de D deve ocorrer após o final da fase de suporte base (5 anos no momento em que este artigo foi escrito) da versão A.

5. Finalmente, uma versão E do Visual Studio pode ser lançada que remove os erros do compilador.

Não serão permitidas alterações que não possam ser tratadas dentro desta estrutura de descontinuação.