Introdução ao Visual Basic

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

A linguagem de programação do Visual Basic pode ser uma linguagem fortemente tipada ou de tipo flexível. A digitação flexível adia grande parte da carga de verificação de tipo até que um programa já esteja em execução. Isso inclui não apenas verificação de tipo de conversões, mas também de chamadas de método, o que significa que a associação de uma chamada de método pode ser adiada até o tempo de execução. Isso é útil ao criar 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 do 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 associação em tempo de execução de chamadas de método. Isso garante o desempenho máximo e ajuda a garantir que as conversões de tipo estejam corretas. Isso é útil ao criar aplicativos de produção nos quais a velocidade de execução e a correção da execução são importantes.

Este documento descreve a linguagem do Visual Basic. Ele deve ser uma descrição completa do idioma em vez de um tutorial de idioma ou um manual de referência de um usuário.

Notação gramatical

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

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

O caso não é importante em programas do Visual Basic. Para simplificar, todos os terminais serão dados em maiúsculas e minúsculas padrão, mas qualquer maiúscula 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 não diferencia largura ao corresponder a terminais, permitindo que caracteres Unicode de largura total correspondam aos equivalentes unicode de meia largura, mas apenas em uma base de token inteiro. Um token não corresponderá se ele contiver caracteres mistos de meia largura e largura total.

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

Compatibilidade

Um recurso importante de uma linguagem de programação é a compatibilidade entre diferentes versões do idioma. Se uma versão mais recente de um idioma não aceitar o mesmo código que uma versão anterior do idioma ou interpretá-la de forma diferente da versão anterior, uma carga poderá ser colocada em um programador ao atualizar seu código de uma versão do idioma para outra. Dessa forma, a compatibilidade entre as versões deve ser preservada, exceto quando o benefício para os consumidores de idiomas é de natureza clara e esmagadora.

A política a seguir rege as alterações no idioma do Visual Basic entre versões. A linguagem de termo, quando usada nesse contexto, refere-se apenas aos aspectos sintacticos e semânticos da própria linguagem do Visual Basic e não inclui nenhuma classe do .NET Framework incluída 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 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 interrupção de compatibilidade pode superar o custo que pode impor aos programadores. Essas situações são:

• Novos avisos. A introdução de um novo aviso não é, por si só, uma interrupção de compatibilidade. No entanto, como muitos desenvolvedores compilam com "tratar avisos como erros" ativados, é 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 de linguagem. Esforços razoáveis serão feitos para escolher palavras-chave que minimizem a possibilidade de colisão com os identificadores dos usuários e usem palavras-chave existentes em que faça sentido. A ajuda será fornecida 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 do idioma, 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 do idioma, mas a especificação do idioma está claramente errada, pode ser necessário alterar a especificação do idioma e o comportamento do compilador. 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 de especificação. Quando a especificação de linguagem deve explicitar o que acontece em uma situação específica, mas não acontece, e o compilador lida com a situação de uma maneira 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 do que acontece no caso c, e o compilador se comporta incorretamente no caso de c, pode ser necessário documentar o que acontece no caso de c e alterar o comportamento do compilador para corresponder. (Observe que, se a especificação for ambígua sobre o que acontece em uma situação e o compilador se comportar de uma maneira claramente errada, o comportamento do compilador se tornará a especificação de fato.)

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

• Omissão de especificação. Quando a especificação de linguagem não permite ou não permite especificamente uma situação específica e o compilador lida com a situação de uma maneira 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. Além da análise de impacto habitual, as alterações desse tipo são ainda mais restritas a casos em que o impacto da alteração é considerado extremamente mínimo e o benefício para os desenvolvedores é muito alto.

• Novos recursos. Em geral, a introdução de novos recursos não deve alterar partes existentes da especificação de idioma 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, essa interrupção de compatibilidade é razoável somente 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 interrupção de compatibilidade, como remover ou modificar um recurso inerentemente inseguro e representar um risco claro de segurança para os usuários.

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

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

• Mais alguma coisa. Caso contrário, o comportamento do compilador permanecerá 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 escopo da alteração? Em outras palavras, quantos programas provavelmente serão afetados? Quantos usuários provavelmente serão afetados? Quão comum será escrever código afetado pela alteração?

• Existe alguma solução alternativa para obter o mesmo comportamento antes da alteração?

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

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

• Quais são os comentários da comunidade sobre a alteração?

Substituição de idioma

Com o tempo, partes do idioma ou do compilador podem ser preteridas. Conforme discutido anteriormente, não é aceitável interromper a compatibilidade para remover esses recursos preteridos. Em vez disso, as seguintes etapas devem ser seguidas:

1. Dado um recurso que existe na versão A do Visual Studio, os comentários devem ser solicitados da comunidade de usuários sobre a substituição do recurso e a notificação completa fornecida antes que qualquer decisão de substituição final seja tomada. O processo de substituição pode ser invertido ou abandonado a qualquer momento com base nos comentários da comunidade de usuários.

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

3. Uma versão completa do 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 posteriormente com os avisos preteridos do compilador convertidos em erros do compilador. O lançamento de D deve ocorrer após o fim da Fase de Suporte Mainstream (5 anos a partir desta gravação) da versão A.

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

As alterações que não podem ser tratadas nessa estrutura de substituição não serão permitidas.