Présentation de Visual Basic

Le langage de programmation Microsoft® Visual Basic® est un langage de programmation de haut niveau pour Microsoft .NET Framework. Bien qu’il soit conçu pour être un langage accessible et facile à apprendre, il est également assez puissant pour répondre aux besoins des programmeurs expérimentés. Le langage de programmation Visual Basic a une syntaxe similaire à l’anglais, qui favorise la clarté et la lisibilité du code Visual Basic. Dans la mesure du possible, les mots ou expressions explicites sont utilisés au lieu d’abréviations, d’acronymes ou de caractères spéciaux. La syntaxe superflue ou inutile est généralement autorisée, mais n’est pas obligatoire.

Le langage de programmation Visual Basic peut être un langage fortement typé ou faiblement typé. La saisie libre reporte la plupart du fardeau de la vérification de type jusqu’à ce qu’un programme soit déjà en cours d’exécution. Cela inclut non seulement la vérification de type des conversions, mais également des appels de méthode, ce qui signifie que la liaison d’un appel de méthode peut être différée jusqu’au moment de l’exécution. Cela est utile lors de la création de prototypes ou d’autres programmes dans lesquels la vitesse de développement est plus importante que la vitesse d’exécution. Le langage de programmation Visual Basic fournit également une sémantique fortement typée qui effectue toutes les vérifications de type au moment de la compilation et interdit la liaison au moment de l’exécution des appels de méthode. Cela garantit des performances maximales et permet de s’assurer que les conversions de type sont correctes. Cela est utile lors de la création d’applications de production dans lesquelles la vitesse d’exécution et la correction de l’exécution sont importantes.

Ce document décrit le langage Visual Basic. Il s’agit d’une description complète du langage plutôt que d’un didacticiel de langue ou du manuel de référence d’un utilisateur.

Notation grammaticale

Cette spécification décrit deux grammaires : une grammaire lexicale et une grammaire syntaxique. La grammaire lexicale définit la façon dont les caractères peuvent être combinés pour former des jetons ; la grammaire syntaxique définit la façon dont les jetons peuvent être combinés pour former des programmes Visual Basic. Il existe également plusieurs grammaires secondaires utilisées pour les opérations de prétraitement telles que la compilation conditionnelle.

Les grammaires de cette spécification sont écrites au format ANTLR - voir http://www.antlr.org/.

Le cas n’est pas important dans les programmes Visual Basic. Par souci de simplicité, tous les terminaux seront donnés dans la casse standard, mais toute casse les correspondra. Les terminaux imprimables du jeu de caractères ASCII sont représentés par leurs caractères ASCII correspondants. Visual Basic n’est pas non plus sensible à la largeur lors de la correspondance de terminaux, ce qui permet aux caractères Unicode de pleine largeur de correspondre à leurs équivalents Unicode à demi-largeur, mais uniquement sur une base de jeton entier. Un jeton ne correspond pas s’il contient des caractères de demi-largeur et de pleine largeur mixtes.

Les sauts de ligne et la mise en retrait peuvent être ajoutés pour la lisibilité et ne font pas partie de la production.

Compatibilité

Une fonctionnalité importante d’un langage de programmation est la compatibilité entre différentes versions du langage. Si une version plus récente d’une langue n’accepte pas le même code qu’une version précédente de la langue ou l’interprète différemment de la version précédente, une charge peut être placée sur un programmeur lors de la mise à niveau de son code d’une version de la langue vers une autre. Par conséquent, la compatibilité entre les versions doit être conservée, sauf si l’avantage pour les consommateurs linguistiques est d’une nature claire et écrasante.

La stratégie suivante régit les modifications apportées au langage Visual Basic entre les versions. Le terme langage, lorsqu’il est utilisé dans ce contexte, fait référence uniquement aux aspects syntaxiques et sémantiques du langage Visual Basic lui-même et n’inclut aucune classe .NET Framework incluse dans le cadre de l’espace Microsoft.VisualBasic de noms (et des sous-espaces de noms). Toutes les classes du .NET Framework sont couvertes par une stratégie de contrôle de version et de compatibilité distincte en dehors de l’étendue de ce document.

Types d’interruptions de compatibilité

Dans un monde idéal, la compatibilité serait de 100% entre la version existante de Visual Basic et toutes les futures versions de Visual Basic. Toutefois, il peut y avoir des situations où la nécessité d’une rupture de compatibilité peut dépasser le coût qu’elle peut imposer aux programmeurs. Ces situations sont les suivantes :

• Nouveaux avertissements. L’introduction d’un nouvel avertissement n’est pas, par elle, un arrêt de compatibilité. Toutefois, étant donné que de nombreux développeurs compilent avec « traiter les avertissements comme des erreurs » activés, vous devez prendre soin de l’introduction d’avertissements.

• Nouveaux mots clés. L’introduction de nouveaux mots clés peut être nécessaire lors de l’introduction de nouvelles fonctionnalités de langage. Des efforts raisonnables seront déployés pour choisir des mots clés qui réduisent la possibilité de collision avec les identificateurs des utilisateurs et d’utiliser des mots clés existants là où il est judicieux. L’aide sera fournie pour mettre à niveau des projets à partir des versions précédentes et échapper les nouveaux mots clés.

• Bogues du compilateur. Lorsque le comportement du compilateur est en désaccord avec un comportement documenté dans la spécification du langage, la correction du comportement du compilateur pour qu’il corresponde au comportement documenté peut être nécessaire.

• Bogue de spécification. Lorsque le compilateur est cohérent avec la spécification du langage, mais que la spécification du langage est clairement incorrecte, la modification de la spécification du langage et le comportement du compilateur peuvent être nécessaires. L’expression « clairement incorrecte » signifie que le comportement documenté s’exécute contre ce qu’une majorité claire et non ambiguë d’utilisateurs attendrait et produit un comportement hautement indésirable pour les utilisateurs.

• Ambiguïté de spécification. Lorsque la spécification du langage doit expliquer ce qui se passe dans une situation particulière, mais pas, et que le compilateur gère la situation d’une manière incohérente ou clairement incorrecte (à l’aide de la même définition à partir du point précédent), il peut être nécessaire de clarifier la spécification et de corriger le comportement du compilateur. En d’autres termes, lorsque la spécification couvre les cas a, b, d et e, mais omet toute mention de ce qui se passe dans le cas c, et que le compilateur se comporte incorrectement dans le cas c, il peut être nécessaire de documenter ce qui se passe dans le cas c et de modifier le comportement du compilateur à mettre en correspondance. (Notez que si la spécification était ambiguë quant à ce qui se passe dans une situation et que le compilateur se comporte d’une manière qui n’est pas clairement incorrecte, le comportement du compilateur devient la spécification de facto.)

• Effectuer des erreurs d’exécution en erreurs au moment de la compilation. Dans un cas où le code est 100% garanti qu’il échoue au moment de l’exécution (c’est-à-dire que le code utilisateur présente un bogue non ambigu dans celui-ci), il peut être souhaitable d’ajouter une erreur au moment de la compilation qui intercepte la situation.

• Omission de spécification. Lorsque la spécification du langage n’autorise pas ou interdit spécifiquement une situation particulière et que le compilateur gère la situation d’une manière qui n’est pas souhaitable (si le comportement du compilateur était clairement incorrect, il s’agit d’un bogue de spécification, et non d’une omission de spécification), il peut être nécessaire de clarifier la spécification et de modifier le comportement du compilateur. En plus de l’analyse d’impact habituelle, les modifications de ce type sont plus limitées aux cas où l’impact du changement est considéré comme extrêmement minimal et l’avantage pour les développeurs est très élevé.

• Nouvelles fonctionnalités. En général, l’introduction de nouvelles fonctionnalités ne doit pas modifier les parties existantes de la spécification du langage ou le comportement existant du compilateur. Dans le cas où l’introduction d’une nouvelle fonctionnalité nécessite la modification de la spécification de langage existante, une telle rupture de compatibilité est raisonnable uniquement si l’impact serait extrêmement minimal et que l’avantage de la fonctionnalité est élevé.

• Sécurité. Dans des situations extraordinaires, les problèmes de sécurité peuvent nécessiter une rupture de compatibilité, comme la suppression ou la modification d’une fonctionnalité intrinsèquement non sécurisée et qui présente un risque de sécurité clair pour les utilisateurs.

Les situations suivantes ne sont pas acceptables pour l’introduction d’interruptions de compatibilité :

• Comportement indésirable ou regrettable. La conception de langage ou le comportement du compilateur qui est raisonnable, mais considéré comme indésirable ou regrettable en rétrospect n’est pas une justification pour la rupture de la compatibilité descendante. Le processus de dépréciation de langue, couvert ci-dessous, doit être utilisé à la place.

• Autre chose. Sinon, le comportement du compilateur reste rétrocompatible.

Critères d’impact

Lorsque vous déterminez si une rupture de compatibilité peut être acceptable, plusieurs critères sont utilisés pour déterminer l’impact de la modification. Plus l’impact est élevé, plus la barre est élevée pour accepter les interruptions de compatibilité.

Les critères sont les suivants :

• Quelle est l’étendue de la modification ? En d’autres termes, combien de programmes sont susceptibles d’être affectés ? Combien d’utilisateurs sont susceptibles d’être affectés ? Quelle est la fréquence d’écriture du code affecté par la modification ?

• Existe-t-il des solutions de contournement pour obtenir le même comportement avant la modification ?

• Quelle est l’évidence du changement ? Les utilisateurs recevront-ils des commentaires immédiats indiquant que quelque chose a changé ou que leurs programmes s’exécuteront-ils différemment ?

• La modification peut-elle être raisonnablement traitée pendant la mise à niveau ? Est-il possible d’écrire un outil qui peut trouver la situation dans laquelle le changement se produit avec une précision parfaite et modifier le code pour contourner le changement ?

• Quelles sont les commentaires de la communauté sur le changement ?

Dépréciation de la langue

Au fil du temps, certaines parties du langage ou du compilateur peuvent devenir déconseillées. Comme indiqué précédemment, il n’est pas acceptable d’interrompre la compatibilité pour supprimer ces fonctionnalités déconseillées. Au lieu de cela, les étapes suivantes doivent être suivies :

1. Étant donné qu’une fonctionnalité existe dans la version A de Visual Studio, les commentaires doivent être sollicités par la communauté des utilisateurs sur la dépréciation de la fonctionnalité et un avis complet donné avant toute décision finale de dépréciation. Le processus de dépréciation peut être inversé ou abandonné à tout moment en fonction des commentaires de la communauté des utilisateurs.

2. version complète (c’est-à-dire pas une version de point) B de Visual Studio doit être publiée avec des avertissements du compilateur qui avertissent l’utilisation déconseillée. Les avertissements doivent être activés par défaut et peuvent être désactivés. Les dépréciations doivent être clairement documentées dans la documentation du produit et sur le web.

3. Une version complète de Visual Studio doit être publiée avec des avertissements du compilateur qui ne peuvent pas être désactivés.

4. Une version complète de Visual Studio doit ensuite être publiée avec les avertissements du compilateur dépréciés convertis en erreurs du compilateur. La publication de D doit se produire après la fin de la phase de support standard (5 ans à compter de cette écriture) de la version A.

5. Enfin, une version E de Visual Studio peut être publiée qui supprime les erreurs du compilateur.

Les modifications qui ne peuvent pas être gérées dans cette infrastructure de dépréciation ne seront pas autorisées.