Úvod do jazyka Visual Basic

Programovací jazyk Microsoft® Visual Basic® je programovací jazyk vysoké úrovně pro rozhraní Microsoft .NET Framework. I když je navržená tak, aby byla přístupná a snadno se učící jazyk, je také dostatečně výkonná, aby vyhovovala potřebám zkušených programátorů. Programovací jazyk Jazyk Visual Basic má syntaxi, která je podobná angličtině, což podporuje srozumitelnost a čitelnost kódu jazyka Visual Basic. Pokud je to možné, smysluplná slova nebo fráze se používají místo zkratek, zkratek nebo speciálních znaků. Nadbytečná nebo nepotřebná syntaxe je obecně povolená, ale nevyžaduje se.

Programovací jazyk jazyka Visual Basic může být buď silně napsaný, nebo volně napsaný jazyk. Volné psaní vztěžuje většinu zátěže kontroly typů, dokud program již není spuštěný. To zahrnuje nejen kontrolu typů převodů, ale také volání metody, což znamená, že vazba volání metody může být odložena do doby běhu. To je užitečné při sestavování prototypů nebo jiných programů, ve kterých je rychlost vývoje důležitější než rychlost provádění. Programovací jazyk Visual Basic také poskytuje sémantiku silného typu, která provádí veškerou kontrolu typů v době kompilace a nepovoluje vazbu volání metody za běhu. To zaručuje maximální výkon a pomáhá zajistit správnost převodů typů. To je užitečné při vytváření produkčních aplikací, ve kterých je důležitá rychlost provádění a správnost provádění.

Tento dokument popisuje jazyk jazyka Visual Basic. Jedná se o úplný popis jazyka, nikoli o kurz jazyka nebo referenční příručku uživatele.

Gramatická notace

Tato specifikace popisuje dvě gramatiky: lexikální gramatiku a syntaktickou gramatiku. Lexikální gramatika definuje, jak lze znaky kombinovat s tvarem tokenů; Syntaktická gramatika definuje, jak lze tokeny zkombinovat do programů jazyka Visual Basic. Pro operace předběžného zpracování, jako je podmíněná kompilace, se používá také několik sekundárních gramatik.

Gramatiky v této specifikaci jsou napsané ve formátu ANTLR - viz http://www.antlr.org/.

Případ není v programech jazyka Visual Basic důležitý. Pro jednoduchost budou všechny terminály uvedeny ve standardním pouzdru, ale jakékoli pouzdro bude odpovídat jim. Terminály, které jsou tisknutelné prvky znakové sady ASCII, jsou reprezentovány odpovídajícími znaky ASCII. Visual Basic také nerozlišuje šířku při porovnávání terminálů, což umožňuje, aby znaky Unicode s plnou šířkou odpovídaly jejich ekvivalentům Unicode s poloviční šířkou, ale pouze na bázi celého tokenu. Token se neshoduje, pokud obsahuje smíšené znaky s poloviční šířkou a plnou šířkou.

Konce řádků a odsazení mohou být přidány pro čitelnost a nejsou součástí produkce.

Kompatibilita

Důležitou funkcí programovacího jazyka je kompatibilita mezi různými verzemi jazyka. Pokud novější verze jazyka nepřijímá stejný kód jako předchozí verze jazyka nebo interpretuje jiný kód než předchozí verze, může být při upgradu kódu z jedné verze jazyka na jinou tíží programátor. Proto musí být zachována kompatibilita mezi verzemi, s výjimkou případů, kdy je výhoda pro spotřebitele jazyka jasná a ohromující.

Následující zásady řídí změny jazyka Visual Basic mezi verzemi. Termín jazyk, pokud se používá v tomto kontextu, odkazuje pouze na syntaktické a sémantické aspekty samotného jazyka Visual Basic a nezahrnuje žádné třídy rozhraní .NET Framework zahrnuté jako součást Microsoft.VisualBasic oboru názvů (a dílčí obory názvů). Všechny třídy v rozhraní .NET Framework jsou pokryty samostatnou zásadou správy verzí a kompatibility mimo rozsah tohoto dokumentu.

Druhy konců kompatibility

V ideálním světě by kompatibilita byla 100% mezi stávající verzí jazyka Visual Basic a všemi budoucími verzemi jazyka Visual Basic. Může však dojít k situacím, kdy potřeba přerušení kompatibility může převažovat nad náklady, které mohou na programátory vyžadovat. Mezi takové situace patří:

• Nová upozornění. Zavedení nového upozornění není konec kompatibility. Vzhledem k tomu, že se mnoho vývojářů kompiluje se zapnutými upozorněními jako chybami, je potřeba při zavádění upozornění věnovat zvláštní pozornost.

• Nová klíčová slova Zavedení nových klíčových slov může být nezbytné při zavádění nových jazykových funkcí. Přiměřené úsilí bude provedeno při výběru klíčových slov, která minimalizují možnost kolize s identifikátory uživatelů a budou používat stávající klíčová slova tam, kde to dává smysl. Nápověda bude poskytována k upgradu projektů z předchozích verzí a uchytá se všemi novými klíčovými slovy.

• Chyby kompilátoru Pokud je chování kompilátoru v rozporu s zdokumentovaným chováním ve specifikaci jazyka, může být nutné opravit chování kompilátoru tak, aby odpovídalo zdokumentovaným chováním.

• Chyba specifikace Pokud je kompilátor konzistentní se specifikací jazyka, ale specifikace jazyka je jasně špatná, může být potřeba změnit specifikaci jazyka a chování kompilátoru. Fráze "jasně špatná" znamená, že zdokumentované chování se spouští proti tomu, co by jasně a jednoznačná většina uživatelů očekávala a produkuje vysoce nežádoucí chování pro uživatele.

• Nejednoznačnost specifikace. Pokud by specifikace jazyka měla vypsat, co se stane v konkrétní situaci, ale ne, a kompilátor situaci zpracuje způsobem, který je buď nekonzistentní nebo jasně nesprávný (pomocí stejné definice z předchozího bodu), objasnění specifikace a oprava chování kompilátoru může být nezbytné. Jinými slovy, když specifikace zahrnuje případy a, b, d a e, ale vynechá jakékoli zmínky o tom, co se stane v případě c, a kompilátor se chová nesprávně v případě c, může být nutné zdokumentovat, co se stane v případě c a změnit chování kompilátoru tak, aby odpovídal. (Všimněte si, že pokud byla specifikace nejednoznačná, co se stane v situaci a kompilátor se chová způsobem, který není jasně špatný, chování kompilátoru se stane specifikací de facto.)

• Provádění chyb za běhu do chyb kompilace V situaci, kdy je kód 100% zaručeno selhání za běhu (tj. uživatelský kód má jednoznačnou chybu), může být žádoucí přidat chybu v době kompilace, která situaci zachytí.

• Specifikace vynechání. Pokud specifikace jazyka výslovně nepovoluje nebo neumožňuje konkrétní situaci a kompilátor situaci zpracovává způsobem, který je nežádoucí (pokud chování kompilátoru bylo jasně nesprávné, bylo by to chyba specifikace, nikoli specifikace vynechání), může být nutné objasnit specifikaci a změnit chování kompilátoru. Kromě obvyklé analýzy dopadu jsou změny tohoto druhu dále omezeny na případy, kdy je dopad změny považován za extrémně minimální a výhoda pro vývojáře je velmi vysoká.

• Nové funkce. Obecně platí, že zavedení nových funkcí by nemělo měnit stávající části specifikace jazyka ani stávající chování kompilátoru. V situaci, kdy zavedení nové funkce vyžaduje změnu stávající specifikace jazyka, je taková kompatibilita přijatelná pouze v případě, že by dopad byl extrémně minimální a výhoda této funkce je vysoká.

• Bezpečnost. V mimořádných situacích mohou obavy zabezpečení vyžadovat přerušení kompatibility, například odebrání nebo úpravy funkce, která je ze své podstaty nezabezpečená a představuje jasné bezpečnostní riziko pro uživatele.

Následující situace nejsou přijatelné důvody pro zavedení konců kompatibility:

• Nežádoucí nebo nešťastné chování. Chování návrhu jazyka nebo kompilátoru, které je rozumné, ale považuje se za nežádoucí nebo nežádoucí v retrospektivě, není odůvodněním způsobujícím zpětnou kompatibilitu. Místo toho se musí použít proces vyřazení jazyka, který je popsaný níže.

• Cokoli jiného. Jinak chování kompilátoru zůstává zpětně kompatibilní.

Kritéria dopadu

Při zvažování, jestli může být konec kompatibility přijatelný, se k určení dopadu změny používá několik kritérií. Čím větší je dopad, tím vyšší je panel pro přijetí konců kompatibility.

Kritéria jsou:

• Jaký je rozsah změny? Jinými slovy, kolik programů bude pravděpodobně ovlivněno? Kolik uživatelů bude pravděpodobně ovlivněno? Jak běžné bude psát kód, který je ovlivněn změnou?

• Existují nějaká alternativní řešení pro získání stejného chování před změnou?

• Jak je tato změna jasná? Dostanou uživatelé okamžitou zpětnou vazbu, že se něco změnilo, nebo se jejich programy budou spouštět jinak?

• Je možné změnu přiměřeně vyřešit během upgradu? Je možné napsat nástroj, který může najít situaci, ve které se změna vyskytuje s dokonalou přesností, a změnit kód tak, aby fungoval kolem této změny?

• Jaká je zpětná vazba komunity na změnu?

Vyřazení jazyka

V průběhu času se části jazyka nebo kompilátoru můžou přestat používat. Jak jsme už probírali dříve, není přijatelné přerušit kompatibilitu, aby se takové zastaralé funkce odebraly. Místo toho je potřeba postupovat následovně:

1. Vzhledem k tomu, že funkce existuje ve verzi A sady Visual Studio, je potřeba požádat komunitu uživatelů o vyřazení této funkce a úplné oznámení před provedením konečného rozhodnutí o vyřazení. Proces vyřazení se může kdykoliv vrátit zpět nebo zrušit na základě zpětné vazby komunity uživatelů.

2. úplná verze (tj. ne bodová verze) Sada Visual Studio musí být vydána s upozorněními kompilátoru, která varují před zastaralým využitím. Upozornění musí být ve výchozím nastavení zapnutá a je možné je vypnout. Vyřazení musí být jasně zdokumentované v dokumentaci k produktu a na webu.

3. Úplná verze jazyka C sady Visual Studio musí být vydána s upozorněními kompilátoru, která nelze vypnout.

4. Následně musí být vydána úplná verze sady Visual Studio s upozorněními zastaralého kompilátoru převedenými na chyby kompilátoru. Vydání D musí proběhnout po skončení fáze hlavní podpory (5 let od tohoto psaní) vydané verze A.

5. Nakonec může být vydána verze E sady Visual Studio, která odstraňuje chyby kompilátoru.

Změny, které nelze zpracovat v rámci této architektury vyřazení, nebudou povoleny.