Inleiding tot Visual Basic

De programmeertaal Microsoft® Visual Basic® is een programmeertaal op hoog niveau voor Microsoft .NET Framework. Hoewel het is ontworpen om een aanpakbare en gemakkelijk te leren taal, is het ook krachtig genoeg om te voldoen aan de behoeften van ervaren programmeurs. De programmeertaal Visual Basic heeft een syntaxis die vergelijkbaar is met het Engels, wat de duidelijkheid en leesbaarheid van Visual Basic-code bevordert. Waar mogelijk worden zinvolle woorden of woordgroepen gebruikt in plaats van afkortingen, acroniemen of speciale tekens. Overbodige of overbodige syntaxis is over het algemeen toegestaan, maar is niet vereist.

De programmeertaal Visual Basic kan een sterk getypte of losjes getypte taal zijn. Bij het losmaken van typen wordt een groot deel van de belasting van typecontrole uitgesteld totdat een programma al wordt uitgevoerd. Dit omvat niet alleen het controleren van typen conversies, maar ook van methodeaanroepen, wat betekent dat de binding van een methodeaanroep kan worden uitgesteld tot de runtime. Dit is handig bij het bouwen van prototypen of andere programma's waarin de snelheid van ontwikkeling belangrijker is dan de uitvoeringssnelheid. De programmeertaal Visual Basic biedt ook sterk getypte semantiek waarmee alle typen worden gecontroleerd tijdens de compilatietijd en het niet mogelijk is om runtime-binding van methode-aanroepen uit te voeren. Dit garandeert maximale prestaties en zorgt ervoor dat typeconversies juist zijn. Dit is handig bij het bouwen van productietoepassingen waarin snelheid van uitvoering en uitvoering belangrijk is.

In dit document wordt de Visual Basic-taal beschreven. Het is bedoeld als een volledige taalbeschrijving in plaats van een taalzelfstudie of een gebruikershandleiding.

Grammatica-notatie

In deze specificatie worden twee grammaticaën beschreven: een lexicale grammatica en een syntactische grammatica. De lexicale grammatica definieert hoe tekens kunnen worden gecombineerd tot formuliertokens; de syntactische grammatica definieert hoe de tokens kunnen worden gecombineerd om Visual Basic-programma's te vormen. Er zijn ook verschillende secundaire grammaticaën die worden gebruikt voor het voorverwerken van bewerkingen, zoals voorwaardelijke compilatie.

De grammatica's in deze specificatie zijn geschreven in ANTLR-indeling - zie http://www.antlr.org/.

Case is niet belangrijk in Visual Basic-programma's. Voor het gemak worden alle terminals gegeven in standaardbehuizing, maar elke behuizing komt overeen met deze. Terminals die afdrukbare elementen van de ASCII-tekenset zijn, worden vertegenwoordigd door de bijbehorende ASCII-tekens. Visual Basic is ook niet gevoelig voor breedte bij overeenkomende terminals, zodat Unicode-tekens met volledige breedte overeenkomen met hun Unicode-equivalenten met halve breedte, maar alleen op basis van een geheel token. Een token komt niet overeen als het gemengde tekens voor halve breedte en volledige breedte bevat.

Regeleinden en inspringing kunnen worden toegevoegd voor leesbaarheid en maken geen deel uit van de productie.

Compatibiliteit

Een belangrijke functie van een programmeertaal is compatibiliteit tussen verschillende versies van de taal. Als een nieuwere versie van een taal niet dezelfde code accepteert als een eerdere versie van de taal of deze anders interpreteert dan de vorige versie, kan een programmeur een last worden gesteld bij het bijwerken van de code van de ene versie van de taal naar de andere. Als zodanig moet de compatibiliteit tussen versies behouden blijven, behalve wanneer het voordeel voor taalgebruikers van een duidelijke en overweldigende aard is.

Het volgende beleid bepaalt wijzigingen in de Visual Basic-taal tussen versies. De termstaal, wanneer deze in deze context wordt gebruikt, verwijst alleen naar de syntactische en semantische aspecten van de Visual Basic-taal zelf en bevat geen .NET Framework-klassen die zijn opgenomen als onderdeel van de Microsoft.VisualBasic naamruimte (en subnaamruimten). Alle klassen in .NET Framework vallen onder een afzonderlijk versiebeheer- en compatibiliteitsbeleid buiten het bereik van dit document.

Soorten compatibiliteitseinden

In een ideale wereld is compatibiliteit 100% tussen de bestaande versie van Visual Basic en alle toekomstige versies van Visual Basic. Er kunnen echter situaties zijn waarin de noodzaak van een compatibiliteitsonderbreking kan wegen tegen de kosten die het voor programmeurs kan opleggen. Dergelijke situaties zijn:

• Nieuwe waarschuwingen. Het introduceren van een nieuwe waarschuwing is geen compatibiliteitsonderbreking. Omdat veel ontwikkelaars echter compileren met 'waarschuwingen als fouten behandelen' ingeschakeld, moet u extra voorzichtig zijn bij het introduceren van waarschuwingen.

• Nieuwe trefwoorden. Het introduceren van nieuwe trefwoorden kan nodig zijn bij het introduceren van nieuwe taalfuncties. Redelijke inspanningen worden gedaan om trefwoorden te kiezen die de kans op conflicten met de id's van gebruikers minimaliseren en bestaande trefwoorden gebruiken waar dit zinvol is. Er wordt hulp geboden om projecten uit eerdere versies te upgraden en nieuwe trefwoorden te ontkomen.

• Compilerfouten. Wanneer het gedrag van de compiler in strijd is met een gedocumenteerd gedrag in de taalspecificatie, is het mogelijk dat het compilergedrag wordt aangepast aan het gedocumenteerde gedrag.

• Specificatiefout. Wanneer de compiler consistent is met de taalspecificatie, maar de taalspecificatie duidelijk onjuist is, kan het wijzigen van de taalspecificatie en het gedrag van de compiler nodig zijn. De zin 'duidelijk onjuist' betekent dat het gedocumenteerde gedrag tegengaat wat een duidelijke en ondubbelzinnige meerderheid van gebruikers zou verwachten en zeer ongewenst gedrag voor gebruikers produceert.

• Dubbelzinnigheid van specificatie. Wanneer de taalspecificatie moet aangeven wat er in een bepaalde situatie gebeurt, maar niet, en de compiler verwerkt de situatie op een manier die inconsistent of duidelijk onjuist is (met dezelfde definitie van het vorige punt), kan het nodig zijn om de specificatie te verduidelijken en het gedrag van de compiler te corrigeren. Met andere woorden, wanneer de specificatie betrekking heeft op gevallen a, b, d en e, maar elke vermelding weglaat van wat er gebeurt in het geval c en de compiler zich onjuist gedraagt in geval c, kan het nodig zijn om vast te leggen wat er gebeurt in het geval c en het gedrag van de compiler te wijzigen zodat deze overeenkomt. (Houd er rekening mee dat als de specificatie dubbelzinnig was over wat er in een situatie gebeurt en de compiler zich gedraagt op een manier die niet duidelijk onjuist is, het gedrag van de compiler de feitelijke specificatie wordt.)

• Runtimefouten maken in compilatie-tijdfouten. In een situatie waarin code 100% gegarandeerd tijdens runtime mislukt (d.w. de gebruikerscode heeft er een ondubbelzinnige fout in), kan het wenselijk zijn om een compilatiefout toe te voegen die de situatie onderschept.

• Specificatie weglating. Wanneer de taalspecificatie een bepaalde situatie niet specifiek toestaat of niet toestaat en de compiler de situatie op een manier afhandelt die ongewenst is (als het compilergedrag duidelijk onjuist was, zou het een specificatiefout zijn, geen specificatie weglating), kan het nodig zijn om de specificatie te verduidelijken en het gedrag van de compiler te wijzigen. Naast de gebruikelijke impactanalyse worden wijzigingen van dit type verder beperkt tot gevallen waarin de impact van de wijziging als zeer minimaal wordt beschouwd en het voordeel voor ontwikkelaars zeer hoog is.

• Nieuwe functies. In het algemeen mag het introduceren van nieuwe functies geen bestaande onderdelen van de taalspecificatie of het bestaande gedrag van de compiler wijzigen. In de situatie waarin het introduceren van een nieuwe functie vereist dat de bestaande taalspecificatie wordt gewijzigd, is een dergelijk compatibiliteitsonderbreking alleen redelijk als de impact uiterst minimaal is en het voordeel van de functie hoog is.

• Beveiliging. In uitzonderlijke situaties kunnen beveiligingsproblemen een compatibiliteitsonderbreking vereisen, zoals het verwijderen of wijzigen van een functie die inherent onveilig is en een duidelijk beveiligingsrisico vormt voor gebruikers.

De volgende situaties zijn niet acceptabel om compatibiliteitseinden in te voeren:

• Ongewenst of betreurenswaardig gedrag. Taalontwerp of compilergedrag dat redelijk is, maar als ongewenst of betreurenswaardig wordt beschouwd in retrospect, is geen reden voor het verbreken van achterwaartse compatibiliteit. Het onderstaande taalafschaffen moet in plaats daarvan worden gebruikt.

• Nog iets. Anders blijft het compilergedrag achterwaarts compatibel.

Impactcriteria

Bij het overwegen of een compatibiliteitsonderbreking acceptabel kan zijn, worden verschillende criteria gebruikt om te bepalen wat de impact van de wijziging kan zijn. Hoe groter de impact, hoe hoger de balk voor het accepteren van de compatibiliteitseinden.

De criteria zijn:

• Wat is het bereik van de wijziging? Met andere woorden, hoeveel programma's worden waarschijnlijk beïnvloed? Hoeveel gebruikers worden waarschijnlijk beïnvloed? Hoe gebruikelijk is het om code te schrijven die wordt beïnvloed door de wijziging?

• Bestaan er tijdelijke oplossingen om hetzelfde gedrag te krijgen vóór de wijziging?

• Hoe duidelijk is de verandering? Krijgen gebruikers onmiddellijk feedback dat er iets is gewijzigd of worden hun programma's gewoon anders uitgevoerd?

• Kan de wijziging redelijkerwijs worden aangepakt tijdens de upgrade? Is het mogelijk om een hulpprogramma te schrijven dat de situatie kan vinden waarin de wijziging plaatsvindt met een perfecte nauwkeurigheid en de code kan wijzigen om de wijziging te omzeilen?

• Wat is de feedback van de community over de wijziging?

Taalafschaffen

Na verloop van tijd kunnen delen van de taal of compiler worden afgeschaft. Zoals eerder besproken, is het niet acceptabel om de compatibiliteit te verbreken om dergelijke afgeschafte functies te verwijderen. In plaats daarvan moeten de volgende stappen worden gevolgd:

1. Gezien een functie die bestaat in versie A van Visual Studio, moet u feedback vragen van de gebruikerscommunity over afschaffing van de functie en volledige kennisgeving die wordt gegeven voordat er een definitieve afschaffingsbeslissing wordt genomen. Het afschaffingsproces kan op elk moment worden teruggedraaid of verlaten op basis van feedback van de gebruikerscommunity.

2. volledige versie (dus geen puntrelease) B van Visual Studio moet worden vrijgegeven met compilerwaarschuwingen die waarschuwen voor afgeschaft gebruik. De waarschuwingen moeten standaard zijn ingeschakeld en kunnen worden uitgeschakeld. De afschaffingen moeten duidelijk worden gedocumenteerd in de productdocumentatie en op het web.

3. Er moet een volledige versie C van Visual Studio worden vrijgegeven met compilerwaarschuwingen die niet kunnen worden uitgeschakeld.

4. Vervolgens moet een volledige versie D van Visual Studio worden vrijgegeven met de afgeschafte compilerwaarschuwingen die zijn geconverteerd naar compilerfouten. De release van D moet plaatsvinden na het einde van de basisondersteuningsfase (5 jaar vanaf dit schrijven) van release A.

5. Ten slotte kan er een versie E van Visual Studio worden uitgebracht waarmee de compilerfouten worden verwijderd.

Wijzigingen die niet binnen dit afschaffingsframework kunnen worden verwerkt, zijn niet toegestaan.